約 3,919,734 件
https://w.atwiki.jp/codboclanlaf/
ここは CALL OF DUTY BLACK OPS 「COD BO」 のクランＬＡＦの公式Wikiです
https://w.atwiki.jp/cod_advancedwarfare/pages/88.html
MORS ゲーム内説明 クラス最高のハンドリング ゲーム内説明(英語) Best in class handling. 性能 分類 スナイパーライフル 解除条件 Level 8 ダメージ 98(HS倍率×1.5 手足以外倍率×1.1) 射撃方式 シングルショット 弾数 1/23 レート 47（次弾装填速度 1.2秒） アタッチメント アタッチメント 解除条件 ACOGスコープ 20kill 可変ズームスコープ 40kill サーマル 60kill バリスティックCPU 80kill ストック HS10kill トラッカー HS20kill パラボラマイク HS30kill アイアンサイト HS40kill サプライドロップ 名前(Name) 分類(Tier) ダメージ(Damage) 精度(Accuracy) レート(Fire Rate) 射程(Range) 操縦性(Handling) 機動性(Mobility) その他 Silver Bullet Elite +2 +1 -2 -1 The Doctor Elite -1 -1 +2 +1 -1 Ransacker Professional +1 +1 -1 -1 Penetrator Professional +1 -1 -1 +1 Tumbler Enlisted +1 -1 Long Rifle Enlisted +1 -1 Quick Bolt Enlisted +1 -1 Slung Enlisted -1 +1 Pummeler Marksman -1 -1 +1 +1 Lullaby -1 +1 バリスティックCPU(キャンペーンでEXO最終強化で入手?) 特徴、考察、補足 単発式だが、装填速度は非常に早くボルトアクション並の連射が可能。 膝から上は即死だが、かすりだとHPを削りきれない為過信は禁物。 胴体即死、かつスコープの換装が可能なのでAtlas 20mmよりかはいくらか扱いやすいものの、単発式故に外した時のカバーがしづらいので正確に狙うこと。 コメント 某ブログ情報だけどサイトでADS速度が変わるらしい。DefaultScope0.4,ThermalScope0.375,IronSite+ACOGScope0.35 可変スコープは分からない - 2015-02-26 01 05 43 お、おう - 2015-02-26 13 15 27 BS分で差が出てるだけじゃね？ - 2015-03-13 18 32 31 皆バリスティックCPU付けてる？ - 2015-02-28 14 15 57 標準スコープを使ってるからCPUつけてるぜよ。 - 2015-02-28 15 37 17 MORSの最強バリアントはThe Doctor Pummeler Quick Bolt - 2015-03-05 13 06 23 異議なし - 2015-03-05 13 17 00 ぼくはクイックボルトが好きです。 - 2015-03-06 21 47 37 ドクターよりレート低く、スプリント硬直遅いのに？ - 2015-03-11 05 04 50 おう - 2015-03-18 17 24 28 今更だが、レートは劣るけど手ぶれ気にするならクイックボルトでいいかもな - 2015-03-18 19 13 20 結局どれも一発目しっかり当てれば同じって言うね。最強もクソもない - 2015-03-13 18 42 19 毎回1発目を必ず当てるとか誰にも無理だし、外れた外したときの性能は大事でしょ。それが言えるのはゴルゴくらいだわ。 - 2015-03-15 17 40 28 SRで1発目外したら大体やられるって考えるのが普通じゃない？外れたときのことを言うならHGなり他武器持つのがベストでしょ。それでもSRのみで戦うって言うならなおさら一撃で倒せるかどうかが重要になってくるでしょ。そもそもで最強の定義って何？伏せて覗いて撃ってもSRだし、腰撃ちで撃ってもSRだとしたら最強って？個人の好みを覆すほどドクターのレート上昇とかが強い、最強とは思わないどれも同じだろう最強もクソもないよねって話。 - 2015-03-16 19 17 58 至近距離は厳しいしけど、二発目のチャンス結構あるよ。たしかにこれが圧倒的に最強というのは決められないくらいの性能差だけど。シルバレとドクターのレートは全然違うけど、両者を同列に比べるのはなんか違う気がするし - 2015-03-18 12 31 56 まず初めに俺は最強と言った人ではない。最強とは言わないけど、間違いなく全て同じはないよ。そこに優劣はある。上記の件以外でも一人キルして次戦への装填時間や他にも色々と特になる部分はある。それが有効かどうかではないんだよ。価値観によって重要視するところは違うだろうからね。一発目で倒せたら全て同じなんてのは全くもって関係ない。それで言うなら最強武器はＳＲだよ。デメリットなしで操舵性が＋１のやつがあったとする、ノーマルと比べてどこがどう有能になったかなんて実感できないけど、でも間違いなく操舵性＋１の方が上なんよ。 - 2015-03-18 13 20 44 SR使うならHGをくらい持つのは普通でしょ。誰もSR縛りで戦う話しはしてないし、HG持つこと前提で話してると思うけど。伏せても腰内でもSRってさ、ゲーム中ずっとそれで戦うわけじゃないから、もし最強を定義付けるとするならそんな例外的なことまで要件として考慮する必要はないと思うよ。たしかにこれが圧倒的に最強というものは決められない性能差だし、好みのレベルだよね。 - 2015-03-18 13 28 26 例外として除いて最強って定義づけるのもありだろうし、むしろ例外まで加えて総合的に最強って考えるのもありだと思うけど、どっちにしろSRに関しては他武器に比べて好みを押しのけるほどのバリアントごとの性能差はないって俺は思う。ただそれだけだけ。HG～についてはある程度蛇足だっな、持つって書いたところは使うって意味で言いたかったんだよ。 - 2015-03-18 23 05 26 まあすまんね - 2015-03-18 23 06 07 ぼ く は P e n e t r a t o r が い い と 思う - 2015-03-15 11 34 55 ちなみにpamajはクイックボルトがお気に入りとのこと - 2015-03-21 10 32 13 自分はSilver Bulletがいい - 2015-03-16 11 30 27 追記見た目かっこいいいいし、性能BO2のDSRみたいだから - 2015-03-16 11 31 14 リロードボタンを押しながら - 2015-03-18 15 27 56 打つと撃つとレートが若干早くなるお(´･ω･｀)みんなも試していい(´･ω･｀) - 2015-03-18 15 30 21 誤字脱字が酷いことになってしまった(´･ω･｀) - 2015-03-18 15 34 49 サーマルって絶対エイムアシスト弱くなってると思う。引っかかりが違う。 - 2015-03-19 02 21 47 シルバーバレットで壁抜きしてる人いる？あれ絶対いらないステータスだと思うんだけど - 2015-03-19 10 39 36 俺もそう思う。今作は壁抜きできる所少ないうえに、砂自体積極的に壁抜き狙って行くもんじゃないしな。 - 2015-03-26 22 15 45 逆にあって何か不便かって言う分けでもないんだからいいじゃん。ただ他強化して個人的に好きな武器を強くしてくれって話でしょ - 2015-03-27 15 10 17 鼻息荒いけどどうした？ - 2015-03-27 15 16 10 そういえば、こいつのアタッチメント解除ってACOGが最初だけどなんでだろうな？普通、可変スコープかCPUじゃね？凸れや、クソ芋という公式からのメッセージか？ - 2015-03-27 21 15 46 すぐ可変スコープが欲しいんだけどな - 2015-04-19 21 02 32 これR2（PS4版）押しっぱなしで連射できるよね。過去作だったら、押しっぱなしにしてもコッキングしたら止まったんだけど。これじゃフルオートだよ！ - 2015-04-27 01 36 44 可変スコープがバグってる十字が表示されない時があるふざけんな - 2015-05-02 14 53 53 レートは+1+2どちらも変わりないらしい。 最強はTheDocterではなく,PummelerかQuickBoltかも知れない。 - 2015-05-05 10 17 05 前まで可変スコープ使ってて最近ノーマルスコープに変えたら全くキル出来なくなったんだけど、、、可変スコープのときは感度10でやっててノーマルスコープは除いたときのエイム遅いから13でやってるんだけどまだ低い感じがする。ノーマルスコープの感度いくらがやり易いのかな？感度はそれぞれの好みあるけど皆の感度知りたいから教えてくれない？ノーマルスコープ以外でもいいから使ってるスコープと感度教えて - 2015-05-30 22 08 31 スナイパー全然やらないんで参考になるかわからんけど、可変とアイアンサイト使ってるよ。感度はどっちも10。 - 2015-05-30 22 46 16 可変スコープは14でノーマルスコープは16くらいかな。アイアンサイトは11。 - 2015-06-01 11 58 50 アイアンサイトも試してみたけど結構低感度の方がやりやすかった気がするな - 2015-05-31 12 23 41 Mors強化万歳。別に今のままでも良いけど強くなるならそれでええわ。 - 2015-06-01 21 57 13 みんなは使いやすいらしいけど、SRで一番使いにくいわ - 2015-06-11 01 44 39 というかまともなSRがmorsしかない - 2015-06-13 12 09 38 Atlas「は？」(威圧) - 2015-06-13 22 00 27 Lynxも慣れたら非常に強力ｯｽ。 - 2015-06-14 01 37 00 NAもデンクロつければ結構戦えるんですけど - 2015-06-14 16 10 03 まともって普通のSRって意味ね。もう一つくらいボルトアクションのSRが欲しかった。 - 2015-06-15 16 22 47 ああ、そう（無関心） - 2015-06-15 17 27 45 は？煽ってるつもりなのか - 2015-06-17 01 52 42 おっ、そうだな（適当） - 2015-06-17 12 32 32 え、うん、そうだよな - 2015-06-17 19 55 54 分かるっちゃ分かる LynxとNaが特殊過ぎてSRと言って良いのやら - 2015-06-18 04 13 18 NAはともかくLynxみたいな連射前提のSRは毎回出てないか？ - 2015-06-25 03 18 30 Gのリンクスは一撃だぞ - 2015-07-01 07 47 12 Lynxそのものの存在を言ってるんじゃなくてAWのLynxみたいなセミスナイパー全般の事を言ってるんだと思うが - 2015-07-01 21 19 23 現在標準のスコープは着弾点が右下にズレているバグがある。←これってまだあるんですか？ - 2015-07-27 18 23 28 ぶっちゃけ気にならないし、もう仕様で通しても大丈夫な気がする - 2015-08-12 17 15 49 二月ごろのアップデートパッチにスナイパースコープの中心点を調整って項目があるな。これじゃないか？ - 2015-08-12 22 08 20 シルバレが威力上がっていると思っていた頃が私にもありました - 2015-08-23 00 28 59 MORSにACOGつけるならどのバリアントがええんかね？The Doctorにつけてやってたら反証(字あってるかな？)多かったんだが - 2015-10-26 10 34 04
https://w.atwiki.jp/cbah/pages/13.html
人気商品一覧 @wikiのwikiモードでは #price_list(カテゴリ名) と入力することで、あるカテゴリの売れ筋商品のリストを表示することができます。 カテゴリには以下のキーワードがご利用できます。 キーワード 表示される内容 ps3 PlayStation3 ps2 PlayStation3 psp PSP wii Wii xbox XBOX nds Nintendo DS desctop-pc デスクトップパソコン note-pc ノートパソコン mp3player デジタルオーディオプレイヤー kaden 家電 aircon エアコン camera カメラ game-toy ゲーム・おもちゃ全般 all 指定無し 空白の場合はランダムな商品が表示されます。 ※このプラグインは価格比較サイト@PRICEのデータを利用しています。 たとえば、 #price_list(game-toy) と入力すると以下のように表示されます。 ゲーム・おもちゃ全般の売れ筋商品 #price_list ノートパソコンの売れ筋商品 #price_list 人気商品リスト #price_list
https://w.atwiki.jp/bullet-bb/pages/55.html
[部分編集] バレットコンボパーツ集(BBCP) 確立されたコンボレシピについては、コンボレシピのページをご覧ください。 [部分編集] 略記 技名 コマンド 略称語 ワッドカット･エンゲージ ドライブ攻撃中D(ヒートアップ時限定) ワッド フリントシューター 236+A(タメ可) フリント、溜めフリント カッティングシア 623+B シア エクスプロード･エンゲージ カッティングシア中22+D(ヒートアップ時限定) エクス ミュクレットキャプチャー 41236+C キャプ ピアッシング･エンゲージ ミュクレットキャプチャー中236+D(ヒートアップ時限定) ピア スナップハンスフィスト 623+C(空中可) ハンス フレシェット･エンゲージ スナップハンスフィスト中623+D(ヒートアップ時限定) フレ アフターバーナー 214+D(タメ可) バーナー レイジアグレッサー 2363214+C レイジ サーペンタインアサルト レバー2回転+A アサルト フランジブル･エンゲージ サーペンタインアサルト中レバー2回転+D フラン ブラックアウト フランジブル･エンゲージ中レバー3回転+D アウト 632146+D AH クラッシュトリガー A+B CT [部分編集] コンボ注意点 2Cは特に表記がない限り2段目まで当てます。 ミュクレットキャプチャーはしゃがみには当たりません。 A ：ノーマル、ヒートアップ問わず繋がる。 N ：ノーマル限定で繋がる。/ノーマル時推奨 H ：ヒートアップ時レベル関係なく繋がる。 H1：ヒートアップレベル1限定で繋がる。/H1時推奨 H2：ヒートアップレベル2限定で繋がる。 位置限定なしA通常 しゃがみ 空中食らい 〆パーツ FC 位置限定なしH通常 位置限定なしH2 中央A 中央H 中央H2～ピア 端A通常 ～キャプ ～ハンス壁ビタ 端H通常 端H2通常 コメント欄 [部分編集] 位置限定なしA 通常 ～2C D H+1 迷ったらこれ。 ～D/JD RC {B,C,6B,D等}～ -50%、H+1 ヒート二段階あげるもよし、追加出して火力優先もよし。 6投げ ステB～ 4投げ 溜めフリント～ 4投げ 6B～ ～C cOD B～ バースト消費 しゃがみ ～C 3C キャプ～ しゃがみ食らい時にキャプに繋ぎたい時のためのパーツ。 C 3Cはしゃがみ限定。 空中食らい ～6A 溜めフリント 6A～ ～6A 溜めフリント 6C jc JC～ ～6A 溜めフリント JB JC 6B～ ～C (3C )キャプ～ ～6A 2B～ ～6A CT～ 25%消費 ～6B JC 6B～ ～JC JA 6B~ ～JC A 6B～ ～JD RC 6B jc JB jc JB JC ハンス フレ レイジ 殺しきり ～6C jc OD{ JB JC} ハンス～ 補正により{}内が入る 〆パーツ ～6B jc{ JB jc JB} JC JD H+1 エリアルはだいたいこれ。 {}内はNだとJDが当たらない可能性が、 また時間制限により途中で受身される可能性がある。 ～B JB dlJC 6B hjc{ JB jc JB} JC JD 5B少し低めで拾った時などに。 {}内はNだとJDが当たらない可能性が、 また時間制限により途中で受身される可能性がある。 JC JA jc JB JC JD ～6B レイジ 50%消費 6Bが当たればどの高さでも入ったはず FC ～C 6C ～C 溜めフリ 屈限 [部分編集] [部分編集] 位置限定なしH 通常 ～ピア ステB～ H→N アサルト フラン 6A～ -50% 補正がキツいのでとっととH回収して締める。 アサルト フラン OD キャプ～ -50%、バースト消費 [部分編集] [部分編集] 位置限定なしH2 ～フレ ステ6A H→N [部分編集] 中央A [部分編集] [部分編集] 中央H [部分編集] [部分編集] 中央H2 ～ピア ～ピア ステ6A H→N ～ピア 低ダJB JC～ H→N 着地j JB JCとかで拾える [部分編集] 端A 通常 6投げ B 6B ハンス 4投げ 溜めフリント 6B/6C ハンス 端維持。後に6Cを使う予定なら6Bで。 ～6C 裏周り2B～ ～キャプ ～キャプ B C 2C D ～キャプ B 6B hjc JC JD ～キャプ 6B jc JC B～ キャラ限 ～ハンス壁ビタ ～ハンス壁ビタ ステ6C jc 降りJC～ ～ハンス壁ビタ ステ6C 裏周り着地B～ ～ハンス壁ビタ ステキャプ～ ～ハンス壁ビタ 低ダJC 6B～ ～ハンス壁ビタ ステCT～ 25％消費 [部分編集] [部分編集] 端H 通常 ～ワッド B～ H→N ～ピア 裏周り6B ハンス H→N 端維持 [部分編集] [部分編集] 端H2 通常 ～ワッド ステ6A 溜めフリント～ H→N コメント欄 すべてのコメントを見る（未作成） 名前
https://w.atwiki.jp/aniwotawiki/pages/36768.html
登録日：2017/05/02 Tue 13 29 26 更新日：2024/01/01 Mon 19 52 53NEW! 所要時間：約 12 分で読めます ▽タグ一覧 Brightly かんざし きらきら きんいろモザイク すこやか ぱっちり もう一人の主人公 ょぅι゛ょ？←いえいえ18歳です アリス アリス・カータレット イギリス人 カスタネット←ではない コニチワ シノ部 ツインテール ロリ 七転八起！ 優柔不断じゃダメだよ有言実行 田中真奈美 番傘 碧眼 金髪 アリス・カータレット。今日もめいっぱい、日本の高校生活楽しみます！ アリス・カータレットは、原悠衣原作の四コマ漫画およびアニメ「きんいろモザイク」の登場人物。 大宮忍と並んで、本編の主人公に該当するキャラである。 所属クラスは1年B組→2年C組→3年A組。 CV：田中真奈美 【プロフィール】 身長：139cm 子供服がぴったり着れるくらい。 誕生日：4月5日 正座：牡羊座 血液型：A型 家族構成：父、母 話し方：子供っぽい 【容姿】 後ろに束ねたツーサイドアップの左側に、桜柄のかんざしをヘアアクセサリーとして差している。 財布はがま口型だが、がま口から下の部分は手人形にもなるペンケースとなっている。 登校時は制服の上に桜色のカーディガンを着ており、 アニメ第1期OPや雨の日に差す朱色の番傘と共にアリスのトレードマークになっている。 一応、忍たちと同い年にあたるが身長が139cmと年の割にあまりにも小さい。 小学生の頃から3cmしか伸びず、高校生になっても小学生に見えるほどで、アリス本人もそれがコンプレックスとなっている。(*1) 【性格】 忍がホームステイに来た際は人見知りが激しく、握手すらできないほどの恥ずかしがり屋だった。 そして金髪フェチな忍が興奮して走り出した際にはあまりの勢いに逃げ出してしまっている。 Japanese girls are so scaryyyyyyyy！！(ジャパニーズガール怖いよ～！！) しかし、彼女との触れ合いの中で忍が「ハロー」と言えばアリスが「コニチワ」と言い返し、互いの言葉は通じなくても、態度と行動で通じ合う仲へと変化する。 寝る前の入浴時、忍が入れた桜の香りのする入浴剤に心を奪われ(*2)、ベッドの上で日本はどんな所なのかと忍に問う。 日本は今、朝ですよ。ふしぎですよね、ここはまだ夜なのにもう太陽が昇ってるんです。なんだか、私たちだけ世界のはじっこに置いてかれてしまったようです……。 I hope visit in Japan......someday.(いつか行ってみたいな……日本。) 通じているような通じていないような、忍の日本での生活を聞きながら、アリスは日本への慕情を募らせるのだった。 高校生になってからも人見知りのクセはまだ治っておらず、忍の後ろを離れないほど見知らぬ相手に緊張してしまう。 あと、近所の吠える犬も苦手。ポピーがアリスによく懐いていたせいだろうか。 また、忍の近所を通り過ぎる髪を染めたコギャルを外国の人と勘違いしたり、暑くないのに朝っぱらから桶と柄杓で打ち水をする、 さらに大宮家で挨拶する際、ヤマトナデシコになるためにおよそ10kgの十二単を着てその重さに耐えながら正座の練習に励んだり、 どこを切っても金太郎の顔が出る金太郎飴を見て「シノみたい」と喜んだりなど、日本に関してちょっとズレた認識を持っている。 朝食は白米に納豆(*3)か青海苔を乗せて食べる派。 その他には味噌汁、焼き鮭に漬物、緑茶と徹底した和風仕立て。ついでに野菜サラダも入っており、食のバランスは取れているようだ。 嫌いな物はグリーンピースで、食べる際に弁当の蓋を置き皿に見立てて箸で分けるほど苦手らしい。 将来の進路は「はっきりと決まってないけど、人の役に立てる人間になりたいな」。人間。By忍ではない。 基本的に子どもっぽく、夜は一人でトイレに行けないほどの幼すぎる性格だが、 ホームステイ時に忍とスコーンを造る際、忍がハートマークを造るのに負けじとドヤ顔でヒトデ星マークを形作ったり、 アリスの姉を自称するカレンには自分が姉だと張り合っては金髪少女好きな忍を取り合ったり、 日本に来て英語の点数が低くなった彼女の答案が回答欄が一行ずつずれてるのを忍に褒められて、 「成績は、わたしの方が上……」としれっと邪な笑みを浮かべたり、と負けず嫌いな面も持っている。 また、「わらしべ長者」の話を聞いて青い両目に￥マークを作って一攫千金をゲス顔で夢見たり…と欲張りな面も見せることもある。 カレンと張り合う時、誕生日プレゼントで富士山の扇子を渡すのに対しカレンが外国の切手を出すのを見て泣きそうになったり、 忍にかっこいい所を見せようと高1の夏休みで渓流釣りで張り切るものの、 結局カレンに負けて落ち込んだり……とアリス自身が敗北感に打ちのめされる場面が目立っていた。小学生か。 また、アニメ第1期6話では絵日記をつける描写が見られていたが、兎のシャーペンで書く達筆な文字に対し画力はまさに小学生レベルで、 第10話Cパートでも放課後で校内かくれんぼする際にも、美術室で絵を描いているが、クレヨンを使って「ツノ」の文字(*4)と共に画用紙に絵を描く様も描写されている。ほほえま～ アリス本人も書店でクロスワードパズル雑誌『くろすわーどわーるど』を読んでる際、通りすがりの女子高生に子どもっぽく見られたのを気にしていたのか、茶道コーナーで盆栽の本を読んだりしている。えー…… 彼女のバイブルは国語辞典。 綾の家でお泊まり会をする際にも持っていこうとして失敗し、勇に止められて泣き出してしまっている。 そんなアリスだが、知らず知らずのうちに日本人より日本人らしくなってしまっていると感じたのか、アリスを見限って新しいブリティッシュガールに浮気するシノという鬼畜な初夢を見てしまい、片言言葉から英会話オンリーで話してしまう行為に走ってしまったことも……。 ??? 日本人らしくなるとサムライになれるデース…？フッフッフ…日本極めるデス、私… 【家族構成・実家】 父・母・アリスの三人構成。愛犬にポピーがおり、アリスと母とは仲良し。 アリスの母は忍の母と友人関係にあたり、日本語を理解できるのもその関係の賜物。英語が話せない忍の助け舟にもなっている。 いろいろな意味でちっちゃいアリスに対し、彼女のアルバム内にある陽子は母の写真(特におっぱい)を見て「アリスは……父ちゃん似かな」としれっとひどいことを言っている。 2年時に犬の話題でもちきりになった時、ポピーの毛並みを思い出してモフりたいゲージがMAXになってリタイアしてしまう。烏丸先生が体を張ってわんこになりきらなかったらやばかった…。 その後、勇が購入した全自動掃除機の上にポピーを模したシノお手製のぬいぐるみを載せることで解決している。(*5) イギリスの実家は石造りの二階構成で、靴のまま上がってもOK。外国っぽい！By忍 キッチンには石窯が置かれており、忍と一緒にスコーンを作ったこともある。 庭園は広く、ティーパーティーも難なくこなせる。 日本に来てからは忍の居候として大宮家に住んでおり、自室は忍と共有している。 忍がベッドで寝るのに対し、アリスは布団で寝る。 布団の隣りにある和式タンスの上には空港で買った京人形、実家にあったこけしと「4」の数字が刻まれた青いジェンガ状の人形が置かれている。 イギリスではお正月のごとくイエス・キリストの誕生日であるクリスマスを祝う風習があり、アリスも日本に来る前は家族と一緒に教会に行ってクリスマスを楽しんでいた。 それ故か、日本でのクリスマスの楽しみ方を独特だと称し、「恋人と過ごすイベントって思ってる人多いよね…」と軽くカルチャーギャップに悩んでいたが、教室内で忍がアリスと過ごすクリスマスが好きと言うや否や、両目をシイタケにして「日本のクリスマスはシノと過ごす日なんだね！素敵！！」とガッツポーズで喜んだ。 ミニスカサンタコスで大はしゃぎするカレンを見てどう思ったか気になるところである。 【学力】 最初は「コニチワ(こんにちは)」しか日本語を話せなかったが、 ふとしたきっかけでびしょ濡れになった忍にケープを手渡した際、忍の「ありがとうございます」に「アリガト……thank you？」と理解するほど洞察力は高い。 基本的に努力家で、日本人であるカレンの父の指導に加え、 こけしを忍に見立てて写経のごとく平仮名を書き続けた甲斐があったのか、日本語を流暢に話せるようになった。 始めて学んだ日本語は「School＝学校」。アニメ第1期最終回のラストで「シノと同じ学校で勉強したい」というアリスの想いが感じられる。 現在では日本暮らしによってほぼ日本語で過ごすようになったせいかカレンともども実家ですら英語を抜いてしゃべるほど。 両家とも一応通じるので問題はないが 日本の学校では難しい日本語を聞いた時に忘れないよう、常に桜色のメモ帳に記入しており、勤勉さが感じられる。 その割には最近好きになった日本語が「ドンマイ＝don't mind」だったり、 玄関の目につくところにジャージを置いておきながら二学期の体育の授業で忘れてしまう、とうっかりな所もある。 日本においても成績は優秀でテストはいつも90点代か100点を取るほど。 それ故か、姉を自称するカレンよりも上だと知るや否や先述のようにしれっと黒い笑顔を見せていたが…。 花札・百人一首・福笑い・青森のだんじり祭り・大文字焼きなど、日本に関する知識は無駄に豊富。 だが花札とかを知らなかった忍に対してやや落胆していた。 アリスの母「『あなたは本当に日本人なのか？』と……」 忍「純日本人ですよ～！」 正座や箸の持ち方も心得ており、前者はグリンピースを難なくつかめるほど器用。 正座の練習の際、なぜか重くて厚くて辛かったという着物の着方も学んでおり、 およそ10kgもあるという十二単もヤマトナデシコになるためにためらいもなく着こなした。 音楽の授業では忍から人を笑顔にさせる歌声と評されており、音楽が大嫌いな綾もこの時は「すごいヒーリング効果だったわ」と喜んでいた。 その言葉を受けてか、忍も「録音して、全国放送で流したらどうでしょう！？ 世界中を笑顔に！」と大袈裟にアピールするが、逆にアリスからドン引きされるのだった。 この後、カレンとのデュエットで第7話挿入歌「さくらいろチェリッシュ」を歌う場面は忍の合いの手も含めてファンからも伝説となっており必見。 体力に関しては見た目通り……というか小学生そのものしかなく、OPや第7話で見られたように1000m走で息も絶え絶えになってしまうほど。 第7話の体育の授業では、喋る時に忍から英語と聞き間違えるくらいに疲れてしまっている。(*6) 【人間関係】 大宮忍 「おっとり優しくて、ヤマトナデシコの鏡だよ」とアリスが評している。 ホームステイ時代から日本に憧れ、彼女と同じ学校に行きたいがために日本に来たことを告白。 忍本人もまた、アリスにずっと会いたかったと告白。忍が風邪をひいて休んだ際には青ざめて心配する、ともはや相思相愛の域に達している。 大人になったらイギリスに行くことを夢見ていただけに、アリスの訪日は予想もしなかったことであった。 アリスの彼女への依存は徹底しており、カレンの金髪になびくのに見入る際にもあれこれ張り合ったり、『シノ部」というものをでっちあげて部長を自称している。シノ年賀状やシノこけしやシノ写真を制作しては周囲に布教することもある。 天使と悪魔の葛藤のイメージではシノが天使役。 忍本人は基本的には金髪少女愛好家だが、特にアリスには「金髪の天使」と称するまでの依存っぷりを見せている。 2年に進級した際、忍と別のクラスになってしまったアリスは、「このクラス、シノがいないんだけどどうしたらいいの……？」(*7)と尋常じゃないくらいに動揺していた。イギリスの実家に帰った時にはカレンにコスプレをさせて「シノごっこ」にまで興じていた。深刻なシノ不足といえる。 忍のイギリス人がもらっても困るようなプレゼントやドレスの着せ替えなどはさすがに死んだような目になることもあるが文句を言うことはめったにない。 猪熊陽子 「明るくて元気。いっぱい食べるのはいいことだよね」とアリスが評しているが、 自己紹介の際に「イノシシにクマで猪熊！ ちょっと強そうでかっこいいでしょ！」と自慢した後、 クマに反応したのか、思わずカタコトで「ﾜ……ﾜﾀｼ､ﾀﾍﾞﾃﾓ､ｵｲｼｸﾅｲﾉﾃﾞ……」で怯えてしまったこともある。 背と胸も小さいアリスにとって、陽子の大きさは色々と羨ましく見えており、その面倒見の良さから『姉御肌』と称している。 なお、腕相撲で姉心でわざと負けた際、「これでクマと出会っても戦えるよ！」とアリスが言った際、 「私、クマじゃないからな！」と速攻でツッコまれた後、カラテごっこに付き合わされるが、当の陽子本人はまんざらでもなさそうだった。 2年目で同じクラスになってからは当然イベントや勉強でのつきあいが多くなった。 付き合いに慣れきってしまったためか勉強に際し九九を言えるかどうかきれいな瞳で疑問を呈したり、「うそつきブラザーズ」こと空太と美月の話題でもちきりになった時に「お姉ちゃんなんだからビシって言わなきゃ！」とお姉ちゃん風を吹かせたり、落ち込んでいる時にマンガ肉の絵を描いて慰めるなど陽子に対し若干ナメた扱いをとることも多い。 小路綾 「頭が良くてしっかり者。だけど時々……すごく、おっちょこちょい」とアリスが評するように、ドジっ子属性を発揮。 第1期2話ではタイツを履き忘れてしまい、忍が靴下を脱いで彼女に貸そうとするのを見られてしまっている。 そんな彼女だが、アリスも自分と同じドジをする部分に親近感を感じているようだ。 2年に進級した際、休み時間で5人が顔合わせた際、互いが互いの想い人にクラス内で会えないのに対して 「ちょっとじゃないわ！ この距離は日本と！！」 「イギリスくらい遠いんだよ！！」 といまだかつてない意気投合を見せている。驚きのめんどくささともいう また、勇のような大人の女性を目指そうと一緒にグレて(笑)みたり姉妹愛に憧れてペアルックにしてみたりという斜め上の趣味を共有することがある。 九条カレン アリスとは幼馴染にして姉妹にも近い関係で、同じ英国人なのか、二人が並ぶと姉妹に見えるほど。 背が小さい頃はアリスの妹役だったが背丈を超すや否や自分がアリスの姉を気取っている。 アリスは結構気にしているのか小さなカレンの夢を見たときに「きれいなカレン」と呼んだ。「どういう意味デス？」 天使と悪魔の葛藤の時はカレンが悪魔役で出てくる。 忍がホームステイしている間は日本語を理解していなかったアリスの妹のふりして一緒に過ごすが一家全員で旅行に行くからと拒否。その代わりに、 「Don't worry！ May be will don't speak sign language, but will can comunicate as long as we try to listine to this heart!(大丈夫！ 言葉が通じなくても心で通じるから！)」 と微笑んで励ますほど、仲がいい。 なおその後忍に懸想して日本語の勉強にはまるアリスにちょっと邪険にされたこともある。 「Alice never listens to me…She's always looking at the Kokeshi doll...She doesn't care about me...(アリスは私の声聞こえてないし…いつもこけしの人形見てるし…私の事なんて)」 それでも結局のところ「ツーカー」の親友同士であり、アリスの後を追うように日本語を学んで実際にやってきた。 忍を巡ってのライバルとしての側面もあるが、カレンはその点に関して自覚的にからかいの対象にしてる節もある。(むろん二人とも忍のことは好き。) ちなみに留学生としてのバランスをとるためか学校で同じクラスになったことがない。金髪キャラかぶりが気になるのかそこは別にいいようだ。(二人ともすぐ遊びに行くしね) なお、アリスがこけしの隣に置かれているジェンガ状の人形は彼女から渡されたお守り代わりのものである。 大宮勇 ほっぺを触ったり、ツインテールを両手で抓んで「金髪がくすんで見えるわ」とからかったりするが、 アリスを忍と同じかわいい妹として愛でている。 アリスからすれば彼女と忍は姉妹なのに尾山人形とこけしの差があるくらい似ていない…らしい。 アリスが居候してからは「妹が二人になったみたいでかわいいわ」と、なんだかんだでシスコンっぷりを見せている。 珍しく忍がいない時には抱きしめて愛でていた。 烏丸さくら 1年の頃は英語を担当。 忍が彼女のような大人になるのを夢見ているのを知り、一時期はなぜかライバル意識を燃やすが、 「Miss Karasuma! Your English sounds a little awkward!」(カラスマ先生！あなたの英語はちょっと変です！)と本場の英語をうっかり喋ってしまい烏丸先生のみならず周囲の喝采を浴びて呆然としてしまったことも。 学級日誌を届けに職員室に向かった際、彼女の「アリスさんはネコだと思う？うさぎだとおもう？」と質問し「うさぎ」と答えるとウサミミを無理矢理つけられてしまうのだった。ﾅﾆｺﾚ……。 小テストの答案にも100点の真下に日の丸の旗がついた花丸を与えたり、かくれんぼに付き合ったりとアリスを溺愛しているが、アリス本人からはちょいちょい子ども扱いしているように感じられている模様。 二学期の体育の授業では彼女のトレードマークであるジャージを借りたこともある(*8)が、第二期最終回で忍をビシビシ指導する際はまんざらでもなさそうに着こなしている。 2年時にはアリスと陽子のクラスの担任を務めており、忍に会えず寂しそうなアリスを不憫に感じたのか、 「先生はまたアリスさんの担任だから、甘えてくれていいんですよー！！」と涙ながらに励ました。 ちなみに烏丸先生はうさぎも飼っており、名前も「アリス」と名付けたことを告げた際、アリス本人からドン引きされたことも……。 久世橋朱里 忍の「ちょっとお姉ちゃんに似ているかもしれません」とその印象を語ったのに反応し、「わかるよ！ 目だよ、目！ 怒ったりからかったりするけど、目の奥は愛情であふれてるんだよ！」と食いついている。 後に、アリスは彼女に強く頼み込んで『シノ2号』という抱き枕を作らせて、教室の隣に置くことに……。くっしーちゃん……余計なことを……！ その後、シノ2号は烏丸先生に回収され職員室ですやすや眠る際に枕として使われている。 松原穂乃花 カレンに対するものほどではないが、金髪少女好きとしてアリスのことも可愛がっている。 忍の嘘アリス自慢「天使の翼が生える」を真面目に信じている節もある。 3年進級の前にはお互いの想い人と離れる可能性について漫才調で対策を話し合い、 こけしに祈りをささげた。 猪熊草太＆美月 陽子の双子の弟・妹で、年下なのかアリスもお姉ちゃんぶろうとするが、背丈のほぼ変わらないのか「ちゃん」づけに留まっている。 その後、買い物途中のアリスに嘘をついて、忍らをも巻き込んで休日に一緒に遊ぶことになるのだった。 【余談】 アリス役の田中真奈美さんは英語が特技で、英検準1級の持ち主。また、高校時代に1年間イギリスに留学した経験を持っている。 声優の道を選んでいなければ通訳家か翻訳家の道を考えていたとのこと。その英語力の高さはラジオ番組「ドキドキうまガール」でも見せており、英語で謝罪する罰ゲームでも英語の発音・アクセントがハッキリしていると話題になった。 アリスの実家のモデルになったのは、実際のイギリスに存在する宿泊地「フォス・ファーム・ハウス」。 1750年に建造された石造りのカントリーハウスで、緑豊かな田園風景が広がるコッツウォルズ地方に存在する。 原作では3コマのみのホームステイ話に実感を持たせるため、 株式会社ジェンコの承認のもと、アニメスタッフが遠路はるばる来訪し、丸一日ロケハンを行った地である。 日本でもTVや料理教室を通して、英国文化を伝える料理研究家キャロン・クーパーさんが切り盛りしており、館内にはスコーン作りも体験できる。 玄関は「Welcome To My House」と書かれたハートマークが中央に飾られた赤いドア、ドアストッパー代わりに置かれたテディベアと劇中でも踏襲されたもの。 アリスの部屋は白を基調としたピンクルーム、忍の部屋は赤と白の枕とベッドが特徴のパインルームがモデルとなっており、 パインルームには忍役の西明日香さんの直筆サインの入ったシノ2号の抱き枕がご丁寧に置かれたことも……。 アリスの父が運転していた車もイギリスに実在したモーリス社の自動車モーリス・マイナーがモデルとなっており、クーパーさんもこれを愛車としている。 また、第一期第1話のイギリスパートでは スティーブン・スピルバーグ監督の映画「戦火の馬」の撮影にも使われたカッスルクーム村、バイブリー村、サイレンセスターなど、 実際にロケハンしたイギリスの町村をモデルとしている。 主要キャラの苗字を京都の通りからとっているきんいろモザイクでは珍しくネーミングにその法則がない。 カータレット／Carteletは作者の原悠衣先生によれば「なんとなく」ついた名前。 アメリカには「カータレット群」という地域がある(*9)がこの綴りは「Carteret」である。 どちらもフランス語に由来するらしいがアリスの苗字のほうがよりフランスぽくかつ希少だそうな。 連載誌であるまんがタイムきららMAXでは、「ご注文はうさぎですか？」の主人公であるココアこと保登心愛と表紙を飾ることがある。 「ごちうさ」アニメシリーズ放送中でのまんがタイムきららMAXのCMでは、 ココアに二度も萌えられてはチノちゃんこと香風智乃に突っ込まれている。 第一期 ココア「アリスちゃんももふもふしたいな～」 チノ「迷惑ですよ」 第二期 ココア「アリスちゃんも私の妹に！」 チノ「ココアさんと同い年ですよ」 そんなアリスだが、2015年4月3日から5月10日にかけてアニメイトで行われた「ハロー！！ きんいろモザイク×ご注文はうさぎですか？ ハロー！！ ぴょんぴょんフェア」では、チノちゃんと組んでいる。 どちらももう一人の主人公的存在でちっちゃい担当であるが、チノちゃんはアリスより年下、アリスが居候する方なのに対しチノちゃんは居候される方。 そして、わずかながらチノちゃん(144㎝)がアリス(139cm)よりも背も高いというのが大きな差だったりする……。 わたし、何もあげられるものないから項目を追記・修正するよ！ △メニュー 項目変更 この項目が面白かったなら……＼ポチッと/ -アニヲタWiki- ▷ コメント欄 [部分編集] きんモザキャラの個別項目が無かったのが意外だった…アリスちゃん可愛いよね、だっこして頭なでなでしたい -- 名無しさん (2017-05-02 19 21 48) 忍ほど極端ではないにせよ、ベッタベタに可愛がりたくなるのはわかる気がする。 -- 名無しさん (2017-05-02 20 22 59) きんモザのキャラ項目ってシノ以外なかったのか、気づかなかった -- 名無しさん (2017-05-02 22 22 27) イギリスに帰ると頭身が伸びる -- 名無しさん (2017-05-02 22 31 54) チノ（中学生）に身長で負けるアリス（高校生）って…ｗ -- 名無しさん (2017-05-02 23 42 59) ↑公式設定ないからわからないけど胸は勝っている・・・と信じたい -- 名無しさん (2017-05-03 00 17 16) アリスちゃんはまな板、チノちゃんは洗濯板…かな -- 名無しさん (2017-05-03 06 59 36) アニメの転校生キャラランキングかなんかで、アリスと花京院が一緒に出てた（画像付きで）。傍から見た場合、この二人が一緒に並んだら何に見えるんだろうか？多分同じ年には見えないだろうね？年の離れた兄妹とか？ -- 名無しさん (2017-05-03 07 47 58) クロスアンジュのアンジュの妹が「きたないアリス」とか言われててめっちゃ笑った -- 名無しさん (2017-05-03 10 28 55) ↑3 どう違うんだ。 -- 名無しさん (2017-05-08 20 01 21) 名前 コメント
https://w.atwiki.jp/srns/pages/51.html
IBM Research Laboratory, San Jose, California Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation). A prompting service which supplies such information is not a satisfactory solution. Activities of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed. Changes in data representation will often be needed as a result of changes in query, update, and report traffic and natural growth in the types of stored information. Existing noninferential, formatted data systems provide users with tree-structured files or slightly more general network models of the data. In Section 1, inadequacies of these models are discussed. A model based on n-ary relations, a normal form for data base relations, and the concept of a universal data sublanguage are introduced. In Section 2, certain operations on relations (other than logical inference) are discussed and applied to the problems of redundancy and consistency in the user’s model. KEY WORDS AND PHRASES data bank, data base, data structure, data organization, hierarchies of data, networks of data, relations, derivability, redundancy, consistency, composition, join, retrieval language, predicate calculus, security, data integrity CR CATEGORIES 3.70, 3.73, 3.75, 4.20, 4.22, 4.29 1. Relational Model and Normal Form 1 .I. INTR~xJ~TI~N This paper is concerned with the application of elementary relation theory to systems which provide shared access to large banks of formatted data. Except for a paper by Childs [l], the principal application of relations to data systems has been to deductive question-answering systems. Levein and Maron [2] provide numerous references to work in this area. In contrast, the problems treated here are those of data independence-the independence of application programs and terminal activities from growth in data types and changes in data representation-and certain kinds of data inconsistency which are expected to become troublesome even in nondeductive systems. Volume 13 / Number 6 / June, 1970 The relational view (or model) of data described in Section 1 appears to be superior in several respects to the graph or network model [3,4] presently in vogue for noninferential systems. It provides a means of describing data with its natural structure only-that is, without superimposing any additional structure for machine representation purposes. Accordingly, it provides a basis for a high level data language which will yield maximal independence between programs on the one hand and machine representation and organization of data on the other. A further advantage of the relational view is that it forms a sound basis for treating derivability, redundancy, and consistency of relations-these are discussed in Section 2. The network model, on the other hand, has spawned a number of confusions, not the least of which is mistaking the derivation of connections for the derivation of relations (see remarks in Section 2 on the “connection trap”). Finally, the relational view permits a clearer evaluation of the scope and logical limitations of present formatted data systems, and also the relative merits (from a logical standpoint) of competing representations of data within a single system. Examples of this clearer perspective are cited in various parts of this paper. Implementations of systems to support the relational model are not discussed. 1.2. DATA DEPENDENCIESIN PRESENTS YSTEMS The provision of data description tables in recently developed information systems represents a major advance toward the goal of data independence [5,6,7]. Such tables facilitate changing certain characteristics of the data representation stored in a data bank. However, the variety of data representation characteristics which can be changed without logically impairing some application programs is still quite limited. Further, the model of data with which users interact is still cluttered with representational properties, particularly in regard to the representation of collections of data (as opposed to individual items). Three of the principal kinds of data dependencies which still need to be removed are ordering dependence, indexing dependence, and access path dependence. In some systems these dependencies are not clearly separable from one another. 1.2.1. Ordering Dependence. Elements of data in a data bank may be stored in a variety of ways, some involving no concern for ordering, some permitting each element to participate in one ordering only, others permitting each element to participate in several orderings. Let us consider those existing systems which either require or permit data elements to be stored in at least one total ordering which is closely associated with the hardware-determined ordering of addresses. For example, the records of a file concerning parts might be stored in ascending order by part serial number. Such systems normally permit application programs to assume that the order of presentation of records from such a file is identical to (or is a subordering of) the Communications of the ACM 377 stored ordering. Those application programs which take advantage of the stored ordering of a file are likely to fail to operate correctly if for some reason it becomes necessary to replace that ordering by a different one. Similar remarks hold for a stored ordering implemented by means of pointers. It is unnecessary to single out any system as an example, because all the well-known information systems that are marketed today fail to make a clear distinction between order of presentation on the one hand and stored ordering on the other. Significant implementation problems must be solved to provide this kind of independence. 1.2.2. Indexing Dependence. In the context of formatted data, an index is usually thought of as a purely performance-oriented component of the data representation. It tends to improve response to queries and updates and, at the same time, slow down response to insertions and deletions. From an informational standpoint, an index is a redundant component of the data representation. If a system uses indices at all and if it is to perform well in an environment with changing patterns of activity on the data bank, an ability to create and destroy indices from time to time will probably be necessary. The question then arises Can application programs and terminal activities remain invariant as indices come and go? Present formatted data systems take widely different approaches to indexing. TDMS [7] unconditionally provides indexing on all attributes. The presently released version of IMS [5] provides the user with a choice for each file a choice between no indexing at all (the hierarchic sequential organization) or indexing on the primary key only (the hierarchic indexed sequent,ial organization). In neither case is the user’s application logic dependent on the existence of the unconditionally provided indices. IDS [8], however, permits the fle designers to select attributes to be indexed and to incorporate indices into the file structure by means of additional chains. Application programs taking advantage of the performance benefit of these indexing chains must refer to those chains by name. Such programs do not operate correctly if these chains are later removed. 1.2.3. Access Path Dependence. Many of the existing formatted data systems provide users with tree-structured files or slightly more general network models of the data. Application programs developed to work with these systems tend to be logically impaired if the trees or networks are changed in structure. A simple example follows. Suppose the data bank contains information about parts and projects. For each part, the part number, part name, part description, quantity-on-hand, and quantity-on-order are recorded. For each project, the project number, project name, project description are recorded. Whenever a project makes use of a certain part, the quantity of that part committed to the given project is also recorded. Suppose that the system requires the user or file designer to declare or define the data in terms of tree structures. Then, any one of the hierarchical structures may be adopted for the information mentioned above (see Structures l-5). 378 Communications of the ACM Structure 1. Projects Subordinate to Parts File Segment Fields F PART part # part name part description quantity-on-hand quantity-on-order PROJECT project # project name project description quantity committed Structure 2. Parts Subordinate to Projects File Sqmeut Fields F PROJECT project # project name project description PART part # part name part description quantity-on-hand quantity-on-order quantity committed Structure 3. Parts and Projects as Peers Commitment Relationship Subordinate to Projects File Segment Fields F PART part # part name part description quantity-on-hand quantity-on-order G PROJECT project # project name project description PART part # quantity committed Structure 4. Parts and Projects as Peers Commitment Relationship Subordinate to Parts File Segnren1 Fields F PART part # part description quantity-on-hand quantity-on-order PROJECT project # quantity committed G PROJECT project # project name project description Structure 5. Parts, Projects, and Commitment Relationship as Peers FCZC .% -,,ZC,,t Ficlds F PART part # part name part description quantity-on-hand quantity-on-order G PROJECT project # project name project description H COMMIT part # project # quantity committed Volume 13 / Number 6 / June, 1970 Now, consider the problem of printing out the part number, part name, and quantity committed for every part used in the project whose project name is “alpha.” The following observations may be made regardless of which available tree-oriented information system is selected to tackle this problem. If a program P is developed for this problem assuming one of the five structures above-that is, P makes no test to determine which structure is in effect- then P will fail on at least three of the remaining structures. More specifically, if P succeeds with structure 5, it will fail with all the others; if P succeeds with structure 3 or 4, it will fail with at least 1,2, and 5; if P succeeds with 1 or 2, it will fail with at least 3, 4, and 5. The reason is simple in each case. In the absence of a test to determine which structure is in effect, P fails because an attempt is made to exceute a reference to a nonexistent file (available systems treat this as an error) or no attempt is made to execute a reference to a file containing needed information. The reader who is not convinced should develop sample programs for this simple problem. Since, in general, it is not practical to develop application programs which test for all tree structurings permitted by the system, these programs fail when a change in ructure becomes necessary. Systems which provide users with a network model of the data run into similar difficulties. In both the tree and network cases, the user (or his program) is required to exploit a collection of user access paths to the data. It does not matter whether these paths are in close correspondence with pointer-defined paths in the stored representation-in IDS the correspondence is extremely simple, in TDMS it is just the opposite. The consequence, regardless of the stored representation, is that terminal activities and programs become dependent on the continued existence of the user access paths. One solution to this is to adopt the policy that once a user access path is defined it will not be made obsolete until all application programs using that path have become obsolete. Such a policy is not practical, because the number of access paths in the total model for the community of users of a data bank would eventually become excessively large. 1.3. A RELATIONAL VIEW OF DATA The term relation is used here in its accepted mathematical sense. Given sets X1 , S, , . . . , S, (not necessarily distinct), R is a relation on these n sets if it is a set of ntuples each of which has its first element from S1, its second element from Sz , and so on.’ We shall refer to Si as the jth domain of R. As defined above, R is said to have degree n. Relations of degree 1 are often called unary, degree 2 binary, degree 3 ternary, and degree n n-ary. For expository reasons, we shall frequently make use of an array representation of relations, but it must be remembered that this particular representation is not an essential part of the relational view being expounded. An ar- 1 More concisely, R is a subset of the Cartesian product 81 X sz x *.* x 87%. ray which represents an n-ary relation R has the following properties (1) Each row represents an n-tuple of R. (2) The ordering of rows is immaterial. (3) All rows are distinct. (4) The ordering of columns is significant-it corresponds to the ordering S1, Sz , . . . , S, of the domains on which R is defined (see, however, remarks below on domain-ordered and domain-unordered relations ) . (5) The significance of each column is partially conveyed by labeling it with the name of the corresponding domain. The example in Figure 1 illustrates a relation of degree 4, called supply, which reflects the shipments-in-progress of parts from specified suppliers to specified projects in specified quantities. supply (supplier part project quantity) 1 2 5 17 1 3 5 23 2 3 7 9 2 7 5 4 4 1 1 12 FIG. 1. A relation of degree 4 One might ask If the columns are labeled by the name of corresponding domains, why should the ordering of columns matter? As the example in Figure 2 shows, two columns may have identical headings (indicating identical domains) but possessd istinct meanings with respect to the relation. The relation depicted is called component. It is a ternary relation, whose first two domains are called part and third domain is called quantity. The meaning of component (2, y, z) is that part x is an immediate component (or subassembly) of part y, and z units of part 5 are needed to assemble one unit of part y. It is a relation which plays a critical role in the parts explosion problem. component (part part quantity) 1 5 9 2 5 7 3 5 2 2 6 12 3 6 3 4 7 1 6 7 1 FIG. 2. A relation with-two identical domains It is a remarkable fact that several existing information systems (chiefly those based on tree-structured files) fail to provide data representations for relations which have two or more identical domains. The present version of IMS/360 [5] is an example of such a system. The totality of data in a data bank may be viewed as a collection of time-varying relations. These relations are of assorted degrees. As time progresses, each n-ary relation may be subject to insertion of additional n-tuples, deletion of existing ones, and alteration of components of any of its existing n-tuples. Volume 13 / Number 6 / June, 1970 Communications of the ACM 379 In many commercial, governmental, and scientific data banks, however, some of the relations are of quite high degree (a degree of 30 is not at all uncommon). Users should not normally be burdened with remembering the domain ordering of any relation (for example, the ordering supplier, then part, then project, then quantity in the relation supply). Accordingly, we propose that users deal, not with relations which are domain-ordered, but with relationships which are their domain-unordered counterparts.2 To accomplish this, domains must be uniquely identifiable at least within any given relation, without using position. Thus, where there are two or more identical domains, we require in each case that the domain name be qualified by a distinctive role name, which serves to identify the role played by that domain in the given relation. For example, in the relation component of Figure 2, the first domain part might be qualified by the role name sub, and the second by super, so that users could deal with the relationship component and its domains-sub.part super.part, quantity-without regard to any ordering between these domains. To sum up, it is proposed that most users should interact with a relational model of the data consisting of a collection of time-varying relationships (rather than relations). Each user need not know more about any relationship than its name together with the names of its domains (role qualified whenever necessary) Even this information might be offered in menu style by the system (subject to security and privacy constraints) upon request by the user. There are usually many alternative ways in which a relational model may be established for a data bank. In order to discuss a preferred way (or normal form), we must first introduce a few additional concepts (active domain, primary key, foreign key, nonsimple domain) and establish some links with terminology currently in use in information systems programming. In the remainder of this paper, we shall not bother to distinguish between relations and relationships except where it appears advantageous to be explicit. Consider an example of a data bank which includes relations concerning parts, projects, and suppliers. One relation called part is defined on the following domains (1) part number (2) part name (3) part color (4) part weight (5) quantity on hand (6) quantity on order and possibly other domains as well. Each of these domains is, in effect, a pool of values, some or all of which may be represented in the data bank at any instant. While it is conceivable that, at some instant, all part colors are present, it is unlikely that all possible part weights, part 2 In mathematical terms, a relationship is an equivalence class of those relations that are equivalent under permutation of domains (see Section 2.1.1). * Naturally, as with any data put into and retrieved from a computer system, the user will normally make far more effective use of the data if he is aware of its meaning. names, and part numbers are. We shall call the set of values represented at some instant the active domain at that instant. Normally, one domain (or combination of domains) of a given relation has values which uniquely identify each element (n-tuple) of that relation. Such a domain (or combination) is called a primary key. In the example above, part number would be a primary key, while part color would not be. A primary key is nonredundant if it is either a simple domain (not a combination) or a combination such that none of the participating simple domains is superfluous in uniquely identifying each element. A relation may possess more than one nonredundant primary key. This would be the case in the example if different parts were always given distinct names. Whenever a relation has two or more nonredundant primary keys, one of them is arbitrarily selected and called the primary key of that relation. A common requirement is for elements of a relation to cross-reference other elements of the same relation or elements of a different relation. Keys provide a user-oriented means (but not the only means) of expressing such crossreferences. We shall call a domain (or domain combmation) of relation R a foreign key if it is not the primary key of R but its elements are values of the primary key of some relation S (the possibility that S and R are identical is not excluded). In the relation supply of Figure 1, the combination of supplier, part, project is the primary key, while each of these three domains taken separately is a foreign key. In previous work there has been a strong tendency to treat the data in a data bank as consisting of two parts, one part consisting of entity descriptions (for example, descriptions of suppliers) and the other part consisting of relations between the various entities or types of entities (for example, the supply relation). This distinction is difficult to maintain when one may have foreign keys in any relation whatsoever. In the user’s relational model there appears to be no advantage to making such a distinction (there may be some advantage, however, when one applies relational concepts to machine representations of the user’s set of relationships). So far, we have discussed examples of relations which are defined on simple domains-domains whose elements are atomic (nondecomposable) values. Nonatomic values can be discussed within the relational framework. Thus, some domains may have relations as elements. These relations may, in turn, be defined on nonsimple domains, and so on. For example, one of the domains on which the relation employee is defined might be salary history. An element of the salary history domain is a binary relation defined on the domain date and the domain salary. The salary history domain is the set of all such binary relations. At any instant of time there are as many instances of the salary history relation in the data bank as there are employees. In contrast, there is only one instance of the employee relation. The terms attribute and repeating group in present data base terminology are roughly analogous to simple domain 380 Communications of the ACM Volume 13 / Number 6 / June, 1970 and nonsimple domain, respectively. Much of the confusion in present terminology is due to failure to distinguish between type and instance (as in “record”) and between components of a user model of the data on the one hand and their machine representation counterparts on the other hand (again, we cite “record” as an example). 1.4. NORMAL FORM A relation whose domains are all simple can be represented in storage by a two-dimensional column-homogeneous array of the kind discussed above. Some more complicated data structure is necessary for a relation with one or more nonsimple domains. For this reason (and others to be cited below) the possibility of eliminating nonsimple domains appears worth investigating! There is, in fact, a very simple elimination procedure, which we shall call normalization. Consider, for example, the collection of relations exhibited in Figure 3 (a). Job history and children are nonsimple domains of the relation employee. Salary history is a nonsimple domain of the relation job history. The tree in Figure 3 (a) shows just these interrelationships of the nonsimple domains. employee I jobhistory I salaryhistory children employee (man#, name, birthdate, jobhistory, children) jobhistory (jobdate, title, salaryhistory) salaryhistory (salarydate, salary) children (childname, birthyear) FIG. 3(a). Unnormalized set employee’ (man#, name, birthdate) jobhistory’ (man#, jobdate, title) salaryhistory’ (man#, jobdate, salarydate, salary) children’ (man#, childname, birthyear) FIG. 3(b). Normalized set Normalization proceeds as follows. Starting with the relation at the top of the tree, take its primary key and expand each of the immediately subordinate relations by inserting this primary key domain or domain combination. The primary key of each expanded relation consists of the primary key before expansion augmented by the primary key copied down from the parent relation. Now, strike out from the parent relation all nonsimple domains, remove the top node of the tree, and repeat the same sequence of operations on each remaining subtree. The result of normalizing the collection of relations in Figure 3 (a) is the collection in Figure 3 (b). The primary key of each relation is italicized to show how such keys are expanded by the normalization. 4 M. E. Sanko of IBM, San Jose, independently recognized the desirability of eliminating nonsimple domains. If normalization as described above is to be applicable, the unnormalized collection of relations must satisfy the following conditions (1) The graph of interrelationships of the nonsimple domains is a collection of trees. (2) No primary key has a component domain which is nonsimple. The writer knows of no application which would require any relaxation of these conditions. Further operations of a normalizing kind are possible. These are not discussed in this paper. The simplicity of the array representation which becomes feasible when all relations are cast in normal form is not only an advantage for storage purposes but also for communication of bulk data between systems which use widely different representations of the data. The communication form would be a suitably compressed version of the array representation and would have the following advantages (1) It would be devoid of pointers (address-valued or displacement-valued ) . (2) It would avoid all dependence on hash addressing schemes. (3) It would contain no indices or ordering lists. If the user’s relational model is set up in normal form, names of items of data in the data bank can take a simpler form than would otherwise be the case. A general name would take a form such as R (g).r.d where R is a relational name; g is a generation identifier (optional); r is a role name (optional); d is a domain name. Since g is needed only when several generations of a given relation exist, or are anticipated to exist, and r is needed only when the relation R has two or more domains named d, the simple form R.d will often be adequate. 1.5. SOME LINGUISTIC ASPECTS The adoption of a relational model of data, as described above, permits the development of a universal data sublanguage based on an applied predicate calculus. A firstorder predicate calculus s ices if the collection of relations is in normal form. Such a language would provide a yardstick of linguistic power for all other proposed data Ianguages, and would itself be a strong candidate for embedding (with appropriate syntactic modification) in a variety of host Ianguages (programming, command- or problemoriented). While it is not the purpose of this paper to describe such a language in detail, its salient features would be as follows. Let us denote the data sublanguage by R and the host language by H. R permits the declaration of relations and their domains. Each declaration of a relation identifies the primary key for that relation. Declared relations are added to the system catalog for use by any members of the user community who have appropriate authorization. H permits supporting declarations which indicate, perhaps less permanently, how these relations are represented in stor- Volume 13 / Number 6 / June, 1970 Communications of the ACM 381 age. R permits the specification for retrieval of any subset of data from the data bank. Action on such a retrieval request is subject to security constraints. The universality of the data sublanguage lies in its descriptive ability (not its computing ability). In a large data bank each subset of the data has a very large number of possible (and sensible) descriptions, even when we assume (as we do) that there is only a finite set of function subroutines to which the system has access for use in qualifying data for retrieval. Thus, the class of qualification expressions which can be used in a set specification must have the descriptive power of the class of well-formed formulas of an applied predicate calculus. It is well known that to preserve this descriptive power it is unnecessary to express (in whatever syntax is chosen) every formula of the selected predicate calculus. For example, just those in prenex normal form are adequate [9]. Arithmetic functions may be needed in the qualification or other parts of retrieval statements. Such functions can be defined in H and invoked in R. A set so specified may be fetched for query purposes only, or it may be held for possible changes. Insertions t,ake the form of adding new elements to declared relations without regard to any ordering that may be present in their machine representation. Deletions which are effective for the community (as opposed to the individual user or subcommunities) take the form of removing elements from declared relations. Some deletions and updates may be triggered by others, if deletion and update dependencies between specified relations are declared in R. One important effect that the view adopted toward data has on the language used to retrieve it is in the naming of data elements and sets. Some aspects of this have been discussed in the previous section. With the usual network view, users will often be burdened with coining and using more relat,ion names than are absolutely necessary, since names are associated with paths (or path types) rather than with relations. Once a user is aware that a certain relation is stored, he will expect to be able to exploit5 it using any combination of its arguments as “knowns” and the remaining arguments as “unknowns,” because the information (like Everest) is there. This is a system feature (missing from many current informat.ion systems) which we shall call (logically) symmetric expZoitation of relations. Naturally, symmetry in performance is not to be expected. To support symmetric exploitation of a single binary relation, two directed paths are needed. For a relation of degree n, the number of paths to be named and controlled is n factorial. Again, if a relational view is adopted in which every nary relation (n 2) has to be expressed by the user as a nested expression involving only binary relations (see Feldman’s LEAP System [lo], for example) then 2n - 1 names have to be coined instead of only n + 1 with direct n-ary notation as described in Section 1.2. For example, the 6 Exploiting a relation includes query, update, and delete. 4-ary relation supply of Figure 1, which entails 5 names in n-ary notation, would be represented in the form P (supplier, (part, R (project, quantity))) in nested binary notation and, thus, employ 7 names. -4 further disadvantage of this kind of expression is its asymmetry. Although this asymmetry does not prohibit symmetric exploitation, it certainly makes some bases of interrogation very awkward for the user to express (consider, for example, a query for those parts and quantities related to certain given projects via and R). 1.6. EXPRESSIBLE, NAMED, AND STORED RELATIONS Associated with a data bank are two collections of relations the named set and the expressible set. The named set is the collection of all those relations that the community of users can identify by means of a simple name (or identifier). A relation R acquires membership in the named set when a suitably authorized user declares R; it loses membership when a suitably authorized user cancels the declaration of R. The expressible set is the total collection of relations that can be designated by expressions in the data language. Such expressions are constructed from simple names of relations in the named set; names of generations, roles and domains; logical connectives; the quantifiers of the predicate calcu- 1~s;~ and certain constant relation symbols such as = , . The named set is a subset of the expressible set-usually a very small subset. Since some relations in the named set may be time-independent combinations of others in that set, it is useful to consider associating with the named set a collection of statements that define these time-independent constraints. We shall postpone further discussion of this until we have introduced several operations on relations (see Section 2). One of the major problems confronting the designer of a data system which is to support a relational model for its users is that of determining the class of stored representations to be supported. Ideally, the variety of permitted data representations should be just adequate to cover the spectrum of performance requirements of the total collection of installations. Too great a variety leads to unnecessary overhead in storage and continual reinterpretation of descriptions for the structures currently in effect. For any selected class of stored representations the data system must provide a means of translating user requests expressed in the data language of the relational model into corresponding-and elhcient-actions on the current stored representation. For a high level data language this presents a challenging design problem. Nevertheless, it is a problem which must be solved-as more users obtain concurrent access to a large data bank, responsibility for providing efficient response and throughput shifts from the individual user to the data system. 6 Because each relation in a practical data bank is a finite set at every instant of time, the existential and universal quantifiers can be expressed in terms of a function that counts the number of elements in any finite set. 382 Communications of the ACM Volume 13 / Number 6 / June, 1970 2. Redundancy and Consistency 2.1. OPERATIONS ON RELATIONS Since relations are sets, all of the usual set operations are applicable to them. Nevertheless, the result may not be a relation; for example, the union of a binary relation and a ternary relation is not a relation. The operations discussed below are specifically for relations. These operations are introduced because of their key role in deriving relations from other relations. Their principal application is in noninferential information systems- systems which do not provide logical inference services-although their applicability is not necessarily destroyed when such services are added. Most users would not be directly concerned with these operations. Information systems designers and people concerned with data bank control should, however, be thoroughly familiar with them. 2.1.1. Permutation. A binary relation has an array representation with two columns. Interchanging these columns yields the converse relation. More generally, if a permutation is applied to the columns of an n-ary relation, the resulting relation is said to be a permutation of the given relation. There are, for example, 4! = 24 permutations of the relation supply in Figure 1, if we include the identity permutation which leaves the ordering of columns unchanged. Since the user’s relational model consists of a collection of relationships (domain-unordered relations), permutation is not relevant to such a model considered in isolation. It is, however, relevant to the consideration of stored representations of the model. In a system which provides symmetric exploitation of relations, the set of queries answerable by a stored relation is identical to the set answerable by any permutation of that relation. Although it is logically unnecessary to store both a relation and some permutation of it, performance considerations could make it advisable. 2.1.2. Projection. Suppose now we select certain columns of a relation (striking out the others) and then remove from the resulting array any duplication in the rows. The final array represents a relation which is said to be a projection of the given relation. A selection operator ?r is used to obtain any desired permutation, projection, or combination of the two operations. Thus, if L is a list of lc indices7 L = i1, ii, - . - , ik and R is an n-ary relation (n 2 k ), then rrL (R ) is the k-ary relation whose jth column is column ii of R (j = 1,2, * * . ,k) except that duplication in resulting rows is removed. Consider the relation supply of Figure 1. A permuted projection of this relation is exhibited in Figure 4. Note that, in this particular case, the projection has fewer n-tuples than the relation from which it is derived. 2.1.3. Join. Suppose we are given two binary relations, which have some domain in common. Under what circumstances can we combine these relations to form a 7 When dealing with relationships, we use domain names (rolequalified whenever necessary) instead of domain positions. ternary relation which preserves all of the information in the given relations? The example in Figure 5 shows two relations R, S, which are joinable without loss of information, while Figure 6 shows a join of R with S. A binary relation R is joinable with a binary relation S if there exists a ternary relation U such that 7r1(2U ) = R and ‘1~23 (U) = S. Any such ternary relation is called a join of R with S. If R, S are binary relations such that ~2 (R) = ~1 (S), then R is joinable with S. One join that always exists in such a case is the natural join of R with S defined by R*S = {(a, b, c) R(a, b) A S(b, c)) where R (a, b) has the value true if (a, b) is a member of R and similarly for S(b, c). It is immediate that and TB(R*S) = R T33(R*S) = S. Note that the join shown in Figure 6 is the natural join of R with S from Figure 5. Another join is shown in Figure 7. II31 hPPb/) (project supplier) 5 1 5 2 1 4 7 2 FIG. 4. A permuted projection of the relation in Figure 1 R (supplier Part) S (part project) 1 1 1 1 2 1 1 2 2 2 2 1 FIG. 5. Two joinable relations R*S (supplier part project) 1 1 1 1 1 2 2 1 1 2 1 2 2 2 1 FIG. 6. The natural join of R with S (from Figure 5) U (supplier part project) 1 1 2 2 1 1 2 2 1 FIG. 7. Another join of R with S (from Figure 5) Inspection of these relations reveals an element (element 1) of the domain part (the domain on which the join is to be made) with the property that it possessesm ore than one relative under R and also under S. It is this ele- Volume 13 / Number 6 / June, 1970 Communications of the ACM 383 ment which gives rise to the plurality of joins. Such an element in the joining domain is called a point of ambiguity with respect to the joining of R with S. If either ~1 (R) or S is a function no point of ambiguity can occur in joining R with S. In such a case, the natural join of R with S is the only join of R with S. Note that the reiterated qualification “of R with S” is necessary, because S might be joinable with R (as well as R with S), and this join would be an entirely separate consideration. In Figure 5, none of the relations R, 7r21(R), S, ?rzl(S) is a function. Ambiguity in the joining of R with S can sometimes be resolved by means of other relations. Suppose we are given, or can derive from sources independent of R and S, a relation T on the domains project and supplier with the following properties (1) m(T) = m(S), (2) m(T) = al(R), (3) T(i s +~P(R( P A S(P,~))~ (4) R(s, P -+ 3j(Soj\,.i) * T(.A s)), (5) S@,.i) + 3s(T(.?, s A R(s, P , then we may form a three-way join of R, S, T; that is, a ternary relation such that mz(U) = R, 7r23(U) = s, ml(U) = T. Such a join will be called a cyclic 3-join to distinguish it from a linear S-join which would be a quaternary relation V such that m(V) = R, lr23W) = s, lr34(V) = T. While it is possible for more than one cyclic 3-join to exist (see Figures 8,9, for an example), the circumstances under which this can occur entail much more severe constraints R (s P) s (P 23 T 0’ s) 1 a a d d 1 2 a 2 b b Ii d 2 e 2 b e e 2 FIG. 8. Binary relations with a plurality of cyclic 3-joins u b P 8 TJ’ (s P i) 1 a d 1 a d 2 a e 2 a d 2 b d 2 a e 2 b e 2 b d 2 b e FIG. 9. Two cyclic 3-joins of the relations in Figure 8 than those for a plurality of 2-joins. To be specific, the relations R, S, T must possess points of ambiguity with respect to joining R with S (say point x), S with T (say 8 A function is a binary relation, which is one-one or many-one, but not one-many. y), and T with R (say a), and, furthermore, y must be a relative of x under S, z a relative of y under T, and x a relative of z under R. Note that in Figure 8 the points 2 = a; y = d; x = 2 have this property. The natural linear 3-join of three binary relations R, S, T is given by R*S*T = { (a, b, c, d) R (a, b) A S (b, c) A T (c, d)} where parentheses are not needed on the left-hand side because the natural 2-join (*) is associative. To obtain the cyclic counterpart, we introduce the operator y which produces a relation of degree n - 1 from a relation of degree n by tying its ends together. Thus, if R is an n-ary relation (n 2 2), the tie of R is defined by the equation r(R) = {(a~, a2, .-. , a,-l) R(ul, az, ... , a,-~, a,) A al = a,). We may now represent the natural cyclic S-join of R, S, T by the expression y (R*S*T). Extension of the notions of linear and cyclic S-join and their natural counterparts to the joining of n binary relations (where n 2 3) is obvious. A few words may be appropriate, however, regarding the joining of relations which are not necessarily binary. Consider the case of two relations R (degree r ), S (degree s) which are to be joined on p of their domains (p T, p s). For simplicity, suppose these p domains are the last p of the r domains of R, and the first p of the s domains of S. If this were not so, we could always apply appropriate permutations to make it so. Now, take the Cartesian product of the first r-p domains of R, and call this new domain A. Take the Cartesian product of the last p domains of R, and call this B. Take the Cartesian product of the last s-p domains of S and call this C. We can treat R as if it were a binary relation on the domains A, B. Similarly, we can treat S as if it were a binary relation on the domains B, C. The notions of linear and cyclic S-join are now directly applicable. A similar approach can be taken with the linear and cyclic n-joins of n relations of assorted degrees. 2.1.4. Composition. The reader is probably familiar with the notion of composition applied to functions. We shall discuss a generalization of that concept and apply it first to binary relations. Our definitions of composition and composability are based very directly on the definitions of join and joinability given above. Suppose we are given two relations R, S. T is a camposition of R with S if there exists a. join U of R with S such that T = aI3 (U) . Thus, two relations are composable if and only if they are joinable. However, the existence of more than one join of R with S does not imply the existence of more than one composition of R with S. Corresponding to the natural join of R with S is the 384 Communications of the ACM Volume 13 / Number 6 / June, 1970 ndural composition9 of R with S defined by R.S = TH(R*S). Taking the relations R, S from Figure 5, their natural composition is exhibited in Figure 10 and another composition is exhibited in Figure 11 (derived from the join exhibited in Figure 7). R. S (project supplier) 1 1 1 2 2 1 FIG. 10. The natural composition of R with S (from Figure 5) T (project supplier) 1 2 2 1 FIQ. 11. Another composition of R with S (from Figure 5) When two or more joins exist, the number of distinct compositions may be as few as one or as many as the number of distinct joins. Figure 12 shows an example of two relations which have several joins but only one composition. Note that the ambiguity of point c is lost in composing R with S, because of unambiguous associations made via the points a, b, d, e. R (supplier part) S (part project) 1 1 z ; ; 1 c c f 2 2 8 is 2 e e f FICA 12. Many joins, only one composition Extension of composition to pairs of relations which are not necessarily binary (and which may be of different degrees) follows the same pattern as extension of pairwise joining to such relations. A lack of understanding of relational composition has led several systems designers into what may be called the connection trap. This trap may be described in terms of the following example. Suppose each supplier description is linked by pointers to the descriptions of each part supplied by that supplier, and each part description is similarly linked to the descriptions of each project which uses that part. A conclusion is now drawn which is, in general, erroneous namely that, if all possible paths are followed from a given supplier via the parts he supplies to the projects using those parts, one will obtain a valid set of all projects supplied by that supplier. Such a conclusion is correct only in the very special case that the target relation between projects and suppliers is, in fact, the natural composition of the other two relations-and we must normally add the phrase “for all time,” because this is usually implied in claims concerning path-following techniques. 0 Other writers tend to ignore compositions other than the natural one, and accordingly refer to this particular composition as the composition-see, for example, Kelley’s “General Topology.” 2.1.5. Restriction. A subset of a relation is a relation. One way in which a relation S may act on a relation R to generate a subset of R is through the operation restriction of R by S. This operation is a generalization of the restriction of a function to a subset of its domain, and is defined as follows. Let L, M be equal-length lists of indices such that L = iI, ., *** ,ik,M = jI,j2, e-s , jk where k 5 degree of R and k 6 degree of S. Then the L, M restriction of R by S denoted RLIMS is the maximal subset R’ of R such that ?rL(R’) = TM(S). The operation is defined only if equality is applicable between elements of ?T+(,R ) on the one hand and rjh (S) on the other for all h = 1, 2, . . . , k. The three relations R, S, R’ of Figure 13 satisfy the equation R = Rw~wsS. R (8 P ~3 s (P 8 R (8 P 3 1aA a A 1aA 2 a A c B 2 a A 2 a B b B 2 b B 2bA 2 b B FIG. 13. Example of restriction We are now in a position to consider various applications of these operations on relations. 2.2. REDUNDANCY Redundancy in the named set of relations must be distinguished from redundancy in the stored set of representations. We are primarily concerned here with the former. To begin with, we need a precise notion of derivability for relations. Suppose 0 is a collection of operations on relations and each operation has the property that from its operands it yields a unique relation (thus natural join is eligible, but join is not ). A relation R is O-derivable from a set S of relations if there exists a sequence of operations from the collection 0 which, for all time, yields R from members of S. The phrase “for all time” is present, because we are dealing with time-varying relations, and our interest is in derivability which holds over a significant period of time. For the named set of relationships in noninferential systems, it appears that an adequate collection contains the following operations projection, natural join, tie, and restriction. Permutation is irrelevant and natural composition need not be included, because it is obtainable by taking a natural join and then a projection. For the stored set of representations, an adequate collection e2 of operations would include permutation and additional operations concerned with subsetting and merging relations, and ordering and connecting their elements. 2.2.1. Strong Redundancy. A set of relations is strongly redundant if it contains at least one relation that possesses a projection which is derivable from other projections of relations in the set. The following two examples are intended to explain why strong redundancy is defined this way, and to demonstrate its practical use. In the first ex- Volume 13 / Number 6 / June, 1970 Communications of the ACM 385 ample the collection of relations consists of just the following relation employee (serial #, name, manager#, managername) with serial# as the primary key and manager# as a foreign key. Let us denote the active domain by A,, and suppose that A, (munuger#) c A, (serial#) and At (managername) C At (name) for all time t. In this case the redundancy is obvious the domain managername is unnecessary. To see that it is a strong redundancy as defined above, we observe that m4 (employee) = ~12 (empZoyee) r3 (employee). In the second example the collection of relations includes a relation S describing suppliers with primary key s#, a relation D describing departments with primary key d#, a relation J describing projects with primary key j#, and the following relations lJ (s#, d#, - * * t Q(s#,j#, .-- , R(d#,j#, **- , where in each case - - - denotes domains other than s#, d#, j#. Let us suppose the following condition C is known to hold independent of time supplier s supplies department d (relation P ) if and only if supplier s supplies some project j (relation Q) to which d is assigned (relation R). Then, we can write the equation m(P) = m(Q)-w(R) and thereby exhibit a strong redundancy. An important reason for the existence of strong redundancies in the named set of relationships is user convenience. A particular case of this is the retention of semiobsolete relationships in the named set so that old programs that refer to them by name can continue to run correctly. Knowledge of the existence of strong redundancies in the named set enables a system or data base administrator greater freedom in the selection of stored representations to cope more efficiently with current traffic. If the strong redundancies in the named set are directly reflected in strong redundancies in the stored set (or if other strong redundancies are introduced into the stored set), then, generally speaking, extra storage space and update time are consumed with a potential drop in query time for some queries and in load on the central processing units. 2.2.2. Weak Redundancy. A second type of redundancy may exist. In contrast to strong redundancy it is not characterized by an equation. A colIection of relations is weakly redundant if it contains a relation that has a projection which is not derivable from other members but is at all times a projection of some join of other projections of relations in the collection. We can exhibit a weak redundancy by taking the second example (cited above) for a strong redundancy, and assuming now that condition C does not hold at all times. The relations al2 (P), 7r1(2Q ), 7r1(2R ) are complexlo relations with the possibility of points of ambiguity occurring from time to time in the potential joining of any two. Under these circumstances, none of them is derivable from the other two. However, constraints do exist between them, since each is a projection of some cyclic join of the three of them. One of the weak redundancies can be characterized by the statement for all time, 1r1(2P ) is somec omposition of ~12(Q ) with ‘~~1(R ). The composition in question might be the natural one at some instant and a nonnatural one at another instant. Generally speaking, weak redundancies are inherent in the logical needs of the community of users. They are not removable by the system or data base administrator. If they appear at all, they appear in both the named set and the stored set of representations. 2.3. CONSISTENCY Whenever the named set of relations is redundant in either sense, we shall associate with that set a collection of statements which define all of the redundancies which hold independent of time between the member relations. If the information system lacks-and it most probably will-detailed semantic information about each named relation, it cannot deduce the redundancies applicable to the named set. It might, over a period of time, make attempts to induce the redundancies, but such attempts would be fallible. Given a collection C of time-varying relations, an associated set Z of constraint statements and an instantaneous value V for C, we shall call the state (C, 2, V) consistent or inconsistent according as V does or does not satisfy 2. For example, given stored relations R, S, T together with the constraint statement “nlz(T) is a composition of 5~1(R2 ) with ~12(X )“, we may check from time to time that the values stored for R, S, T satisfy this constraint. An algorithm for making this check would examine the first two columns of each of R, S, T (in whatever way they are represented in the system) and determine whether (1) ?rl(T) = rl(R), (2) ?rz(T) = 7r2@), (3) for every element pair (a, c) in the relation al2 (T) there is an element b such that (a, b) is in a12(R) and (b, c) is in 7r12(S). There are practica1 problems (which we shall not discuss here) in taking an instantaneous snapshot of a collection of relations, some of which may be very large and highly variable. It is important to note that consistency as defined above is a property of the instantaneous state of a data bank, and is independent of how that state came about. Thus, in particular, there is no distinction made on the basis of whether a user generated an inconsistency due to an act of omission or an act of commission. Examination of a simple IO A binary relation is complex if neither it nor its converse is a function. 386 Communications of the AMC Volume 13 / Number 6 / June, 1970 example will show the reasonableness of this (possibly unconventional) approach to consistency. Suppose the named set C includes the relations S, J, D, P, Q, R of the example in Section 2.2 and that P, Q, R possess either the strong or weak redundancies described therein (in the particular case now under consideration, it does not matter which kind of redundancy occurs). Further, suppose that at some time t the data bank state is consistent and contains no project j such that supplier 2 supplies project j and j is assigned to department 5. Accordingly, there is no element (2,5) in ~12 (P). Now, a user introduces the element (2, 5) into 7~1(2P ) by inserting some appropriate element into P. The data bank state is now inconsistent. The inconsistency could have arisen from an act of omission, if the input (2, 5) is correct, and there does exist a project j such that supplier 2 supplies j and j is assigned to department 5. In this case, it is very likely that the user intends in the near future to insert elements into Q and R which will have the effect of introducing (2, j) into al2 (Q) and (5, j) in W(R). On the other hand, the input (2, 5) might have been faulty. It could be the case that the user intended to insert some other element into P-an element whose insertion would transform a consistent state into a consistent state. The point is that the system will normally have no way of resolving this question without interrogating its environment (perhaps the user who created the inconsistency ). There are, of course, several possible ways in which a system can detect inconsistencies and respond to them. In one approach the system checks for possible inconsistency whenever an insertion, deletion, or key update occurs. Naturally, such checking will slow these operations down. If an inconsistency has been generated, details are logged internally, and if it is not remedied within some reasonable time interval, either the user or someone responsible for the security and integrity of the data is notified. Another approach is to conduct consistency checking as a batch operation once a day or less frequently. Inputs causing the inconsistencies which remain in the data bank state at checking time can be tracked down if the system maintains a journal of all state-changing transactions. This latter approach would certainly be superior if few nontransitory inconsistencies occurred. 2.4. SUMMARY In Section 1 a relational model of data is proposed as a basis for protecting users of formatted data systems from the potentially disruptive changes in data representation caused by growth in the data bank and changes in traffic. A normal form for the time-varying collection of relationships is introduced. In Section 2 operations on relations and two types of redundancy are defined and applied to the problem of maintaining the data in a consistent state. This is bound to become a serious practical problem as more and more different types of data are integrated together into common data banks. Many questions are raised and left unanswered. For example, only a few of the more important properties of the data sublanguage in Section 1.4 are mentioned. Neither the purely linguistic details of such a language nor the implementation problems are discussed. Nevertheless, the material presented should be adequate for experienced systems programmers to visualize several approaches. It is also hoped that this paper can contribute to greater precision in work on formatted data systems. Acknowledgment. It was C. T. Davies of IBM Poughkeepsie who convinced the author of the need for data independence in future information systems. The author wishes to thank him and also F. P. Palermo, C. P. Wang, E. B. Altman, and M. E. Senko of the IBM San Jose Research Laboratory for helpful discussions. RECEIVED SEPTEMBER, 1969; REVISED FEBRUARY, 1970 REFERENCES 1. CHILDS, D. L. Feasibility of a set-theoretical data structure -a general structure based on a reconstituted definition of relation. Proc. IFIP Cong., 1968, North Holland Pub. Co., Amsterdam, p. 162-172. 2. LEVEIN, R. E., AND MARON, M. E. A computer system for inference execution and data retrieval. Comm. ACM 10, 11 (Nov. 1967), 715-721. 3. BACHMAN, C. W. Software for random access processing. Datumation (Apr. 1965), 3641. 4. MCGEE, W. C. Generalized file processing. In Annual Review in Automatic Programming 6, 13, Pergamon Press, New York, 1969, pp. 77-149. 5. Information Management System/360, Application Description Manual H20-0524-1. IBM Corp., White Plains, N. Y., July 1968. 6. GIS (Generalized Information System), Application Description Manual H20-0574. IBM Corp., White Plains, N. Y., 1965. 7. BLEIER, R. E. Treating hierarchical data structures in the SDC time-shared data management system (TDMS). Proc. ACM 22nd Nat. Conf., 1967, MD1 Publications, Wayne, Pa., pp. 41-49. 8. IDS Reference Manual GE 625/635, GE Inform. Sys. Div., Pheonix, Ariz., CPB 1093B, Feb. 1968. 9. CHURCH, A. An Introduction to Mathematical Logic I. Princeton U. Press, Princeton, N.J., 1956. 10. FELDMAN, J. A., AND ROVNER, P. D. An Algol-based associative language. Stanford Artificial Intelligence Rep. AI-66, Aug. 1, 1968. Volume 13 / Number 6 / June, 1970 Communications of the ACM 38’7
https://w.atwiki.jp/sunetyama/pages/4.html
ニュース @wikiのwikiモードでは #news(興味のある単語) と入力することで、あるキーワードに関連するニュース一覧を表示することができます 詳しくはこちらをご覧ください。 ＝＞http //atwiki.jp/guide/17_174_ja.html たとえば、#news(wiki)と入力すると以下のように表示されます。 【グランサガ】リセマラ当たりランキング - グランサガ攻略wiki - Gamerch(ゲーマチ) Among Us攻略Wiki【アマングアス・アモングアス】 - Gamerch(ゲーマチ) 【ひなこい】最強ひな写ランキング - ひなこい攻略Wiki - Gamerch(ゲーマチ) マニュアル作成に便利な「画像編集」機能を提供開始！ - ナレッジ共有・社内wikiツール「NotePM」 - ヨコハマ経済新聞 【Apex Legends】ヴァルキリーの能力と評価【エーペックス】 - Gamerch(ゲーマチ) モンハンライズ攻略Wiki｜MHRise - AppMedia(アップメディア) 【ウインドボーイズ】リセマラ当たりランキング（最新版） - ウインドボーイズ攻略Wiki - Gamerch(ゲーマチ) ポケモンBDSP(ダイパリメイク)攻略wiki - AppMedia(アップメディア) 【テイルズオブルミナリア】リセマラ当たりランキング - TOルミナリア攻略Wiki - Gamerch(ゲーマチ) SlackからWikiへ！シームレスな文章作成・共有が可能な「GROWIBot」リリース - アットプレス（プレスリリース） 【ウマ娘】チャンピオンズミーティングの攻略まとめ - Gamerch(ゲーマチ) 【ウマ娘】ナリタブライアンの育成論｜URAシナリオ - Gamerch(ゲーマチ) 【ウマ娘】ヒシアケボノの育成論｜URAシナリオ - Gamerch(ゲーマチ) 【ウマ娘】フジキセキの育成論｜URAシナリオ - Gamerch(ゲーマチ) ドラゴンクエストけしケシ攻略Wiki - Gamerch(ゲーマチ) サモンズボード攻略wiki - GameWith 【スタオケ】カード一覧【金色のコルダスターライトオーケストラ】 - Gamerch(ゲーマチ) 【ブレフロレゾナ】リセマラ当たりランキング【ブレイブフロンティアレゾナ】 - ブレフロR攻略Wiki - Gamerch(ゲーマチ) 【ポケモンユナイト】サーナイトの評価と性能詳細【UNITE】 - Gamerch(ゲーマチ) 【ガーディアンテイルズ】ギルドレイド戦（秘密の研究所）の攻略とおすすめキャラ【ガデテル】 - Gamerch(ゲーマチ) 仲村トオル、共演者は事前に“Wiki調べ” - 沖縄タイムス 【ENDER LILIES】攻略チャートと全体マップ【エンダーリリィズ】 - Gamerch(ゲーマチ) 【ウマ娘】あんしん笹針師の選択肢はどれを選ぶべき？ - Gamerch(ゲーマチ) 【ポケモンユナイト】アップデート情報・キャラ調整まとめ - ポケモンユナイト攻略Wiki - Gamerch(ゲーマチ) 【Apex】シーズン11の新要素と最新情報まとめ【エーペックス】 - Gamerch(ゲーマチ) ロストジャッジメント攻略Wiki - Gamerch(ゲーマチ) 【Among us】新マップThe Airship（エアシップ）の解説【アモングアス】 - Gamerch(ゲーマチ) ハーネスについて小児科医の立場から考える（坂本昌彦） - 個人 - Yahoo!ニュース - Yahoo!ニュース ゼルダ無双攻略Wiki｜厄災の黙示録 - AppMedia(アップメディア) ウマ娘攻略Wiki - AppMedia(アップメディア) ゲトメア（ゲートオブナイトメア）攻略Wiki - Gamerch(ゲーマチ) 【白夜極光】リセマラ当たりランキング - 白夜 極光 wiki - Gamerch(ゲーマチ) お蔵入りとなった幻の『スーパーマリオ』 オランダの博物館でプレイ可能？（リアルサウンド） - Yahoo!ニュース - Yahoo!ニュース ナレッジ共有・社内wikiツール「NotePM」が「ITreview Best Software in Japan 2021」のTOP50に選出 - PR TIMES 真女神転生5攻略Wiki｜メガテン5 - AppMedia(アップメディア) 【B4B】近接ビルドデッキにおすすめのカード【back4blood】 - Gamerch(ゲーマチ) ポケモンスナップ攻略wiki - AppMedia(アップメディア) 富野由悠季「ブレンパワード」作り直したい！ファンを前に意欲（シネマトゥデイ） - Yahoo!ニュース - Yahoo!ニュース 【ウマ娘】査定効率から見た取るべきスキルとおすすめキャラ【プリティーダービー】 - Gamerch(ゲーマチ) 【スマブラSP】カズヤの評価とコンボ【スマブラスペシャル】 - Gamerch(ゲーマチ) ナレッジ共有・社内wiki「NotePM」が「ITreview Grid Award 2021 Fall」で、チームコラボレーションとマニュアル作成部門において「Leader」を5期連続でW受賞！ - PR TIMES メモ・ドキュメント・wiki・プロジェクト管理などオールインワンのワークスペース「Notion」が日本語ベータ版提供開始 - TechCrunch Japan 【ギアジェネ】リセマラ当たりランキング【コードギアス】 - ギアジェネ攻略Wiki - Gamerch(ゲーマチ) モンスターファーム2(MF2)攻略wiki｜アプリ・Switch移植版 - AppMedia(アップメディア) 【ブラサジ】最強キャラTierランキング【ブラックサージナイト】 - Gamerch(ゲーマチ) 【パワプロ】鬼滅の刃コラボ情報まとめ - Gamerch(ゲーマチ) 【SPAJAM2021】第3回予選大会は「クイズ!WIKIにゃんず!」を開発したチーム「かよちゃんず」が最優秀賞！ | gamebiz - SocialGameInfo 検索結果における「ナレッジパネル」の役割とは・・・ウィキメディア財団とDuckDuckGoの共同調査 - Media Innovation ナレッジ共有・社内wikiツール「NotePM」が「BOXIL SaaS AWARD 2021 Autumn」にて「コラボレーション部門」を受賞！ - PR TIMES 【ポケモンユナイト】カメックスの評価と立ち回り【UNITE】 - Gamerch(ゲーマチ) Wikipediaが「中国人編集者の身の安全を守るため」に一部の編集者アカウントをBANに - GIGAZINE 【ドッカンバトル】3.5億ダウンロードキャンペーン最新情報 - ドッカンバトル攻略Wiki - Gamerch(ゲーマチ) BTS（防弾少年団）のV、8月のWikipedia閲覧数が韓国アーティストで1位！グループでは4ヶ月連続トップ - Kstyle 【イース6オンライン】リセマラ当たりランキング｜召喚ガチャの開放条件は？ - Gamerch(ゲーマチ) BacklogからNotePMへwiki情報を自動API連携する「Backlog to NotePM」をSaaStainerに掲載開始 - PR TIMES ライザのアトリエ2攻略Wiki - AppMedia(アップメディア) 真女神転生3リマスター攻略Wiki｜メガテン3 - AppMedia(アップメディア) タスクも文書もWikiもデータベースもまとめて管理できる「Notion」とは？ - ASCII.jp ナレッジ共有・社内wikiツール「NotePM」が、見るだけ専用ユーザー『無料』の新プランを発表！ - PR TIMES 【かのぱず】リセマラ当たりランキング【彼女お借りします】 - Gamerch(ゲーマチ) 【乃木フラ】リセマラの必要はある？【乃木坂的フラクタル】 - Gamerch(ゲーマチ) メトロイド ドレッド攻略Wiki - Gamerch(ゲーマチ) 【パワプロ】生放送まとめ｜パワフェス2021 - パワプロ攻略Wiki - Gamerch(ゲーマチ) ルーンファクトリー5攻略wiki｜ルンファク5 - AppMedia(アップメディア) シャーマンキングふんばりクロニクル攻略Wiki - Gamerch(ゲーマチ) 簡単操作で自分専用Wikiを構築できるMarkdownエディタ「Obsidian」のモバイル版を使ってみた - GIGAZINE ディーサイドトロイメライ攻略Wiki - Gamerch(ゲーマチ) 情報マネジメントツール「Huddler」がwiki機能を刷新 - PR TIMES シェアエコ配送アプリ「DIAq(ダイヤク)」のアンカーアプリで、高層ビル・商業施設の入館方法などお役立ち情報をまとめた「DIAqwiki」を公開 - アットプレス（プレスリリース） 異常熱波のカナダで49.6度、いま北米で起きていること（森さやか） - 個人 - Yahoo!ニュース - Yahoo!ニュース 【ツイステ】マスターシェフの攻略～辛味のふるさと～【料理イベント】 - Gamerch(ゲーマチ) 【ラグナロクオリジン】リセマラは不要？おすすめ職業は？【ラグオリ】 - Gamerch(ゲーマチ) 白夜極光攻略wiki - AppMedia(アップメディア) 【バイオミュータント】2.02アプデ｜アップデート1.4情報 - バイオミュータント攻略Wiki - Gamerch(ゲーマチ) ニーアレプリカントリメイク攻略wiki｜ver.1.22 - AppMedia(アップメディア) 【ウマ娘】ゴルシウィークはいつから？キャンペーン情報まとめ - Gamerch(ゲーマチ) シーズン66 - 【超速GP】ミニ四駆 超速グランプリ攻略まとめwiki - 電撃オンライン 乃木坂的フラクタル攻略Wiki - Gamerch(ゲーマチ) 「こんなことになるとは…」13年前のエイプリルフールについた“嘘”がネットで… ある男の告白（BuzzFeed Japan） - Yahoo!ニュース - Yahoo!ニュース 【ウマ娘】DMM版のデータ連携のやり方とメリット【プリティーダービー】 - Gamerch(ゲーマチ) 整理不要の情報共有ツール(社内Wiki)「Nerve」シードラウンドで総額約3500万円の資金調達を実施 - PR TIMES Nerve - 整理不要の情報共有ツール(社内Wiki) ローンチカスタマー募集開始のお知らせ - PR TIMES パニシンググレイレイヴン(パニグレ)攻略wiki - Gamerch(ゲーマチ) 稲作アクションRPG『天穂のサクナヒメ』における「農林水産省攻略wiki説」は本当なのか？ - AUTOMATON スタスマ攻略Wiki【スタースマッシュ】 - Gamerch(ゲーマチ) 無料とは思えない多機能っぷりなWikiインフラ「Wiki.js」レビュー、自前でホスト＆外部サービスと連携可能 - GIGAZINE Microsoft Teamsの基本と活用(24) TeamsのWikiを使う - マイナビニュース 『ゲーミングお嬢様』での提起が話題に “企業系wiki”に横たわる問題点とは - リアルサウンド 「エイリアンのたまご」，自動周回機能と公式wikiが登場 - 4Gamer.net 【リゼロス】Re ゼロから始める異世界生活 Lost in Memories攻略まとめwiki - 電撃オンライン 【世界初！】モノの背景を全方位で執筆できるVintage Wiki「VOV」を正式リリース - PR TIMES 足もとのベストアンサーを“編集”！ Wikiペディキュア！ - ビューティ特集 | SPUR - SPUR.JP パワプロ2021／2020攻略Wiki - Gamerch(ゲーマチ) ヌーラボ、「Backlog」の絵文字入力の補完機能やWiki編集の自動マージ機能を改善 - CodeZine（コードジン） ヌーラボ、プロジェクト管理ツール「Backlog」の絵文字入力の補完機能・Wiki編集の自動マージ機能を修正改善 - PR TIMES アサルトリリィ Last Bullet 攻略Wiki【ラスバレ】 - Gamerch(ゲーマチ) SHOW BY ROCK!! Fes A Live攻略wiki - Gamerch(ゲーマチ) Backlog、Wikiにファイル添付が容易にできる機能をリリース -- グローバルバーの視認性改善なども実施 - PR TIMES GK川島、パンチング失点でWiki書き換え炎上 「セネガル代表」「プロボクサー」... - J-CASTニュース Wikipediaで「ヒト」を象徴する画像が、タイの男女に決まるまで 5年の激論を経て選ばれた「1枚」の物語 - WIRED.jp
https://w.atwiki.jp/cod5zombies/pages/4.html
ニュース @wikiのwikiモードでは #news(興味のある単語) と入力することで、あるキーワードに関連するニュース一覧を表示することができます 詳しくはこちらをご覧ください。 ＝＞http //atwiki.jp/guide/17_174_ja.html たとえば、#news(wiki)と入力すると以下のように表示されます。 SlackからWikiへ！シームレスな文章作成・共有が可能な「GROWIBot」リリース - アットプレス（プレスリリース） 【グランサガ】リセマラ当たりランキング - グランサガ攻略wiki - Gamerch(ゲーマチ) ポケモンBDSP(ダイパリメイク)攻略wiki - AppMedia(アップメディア) 【ひなこい】最強ひな写ランキング - ひなこい攻略Wiki - Gamerch(ゲーマチ) モンハンライズ攻略Wiki｜MHRise - AppMedia(アップメディア) ノンスタ石田 自身Wikiに困惑 - auone.jp 【スタオケ】カード一覧【金色のコルダスターライトオーケストラ】 - Gamerch(ゲーマチ) 【スマブラSP】ソラのコンボと評価【スマブラスペシャル】 - Gamerch(ゲーマチ) 【ブレフロレゾナ】リセマラ当たりランキング【ブレイブフロンティアレゾナ】 - ブレフロR攻略Wiki - Gamerch(ゲーマチ) 【ポケモンユナイト】サーナイトの評価と性能詳細【UNITE】 - Gamerch(ゲーマチ) 【ウインドボーイズ】リセマラ当たりランキング（最新版） - ウインドボーイズ攻略Wiki - Gamerch(ゲーマチ) 仲村トオル、共演者は事前に“Wiki調べ”（オリコン） - Yahoo!ニュース - Yahoo!ニュース 【ENDER LILIES】攻略チャートと全体マップ【エンダーリリィズ】 - Gamerch(ゲーマチ) 【ウマ娘】あんしん笹針師の選択肢はどれを選ぶべき？ - Gamerch(ゲーマチ) 【ポケモンユナイト】アップデート情報・キャラ調整まとめ - ポケモンユナイト攻略Wiki - Gamerch(ゲーマチ) 【Apex】シーズン11の新要素と最新情報まとめ【エーペックス】 - Gamerch(ゲーマチ) ロストジャッジメント攻略Wiki - Gamerch(ゲーマチ) 【Among us】新マップThe Airship（エアシップ）の解説【アモングアス】 - Gamerch(ゲーマチ) ハーネスについて小児科医の立場から考える（坂本昌彦） - 個人 - Yahoo!ニュース - Yahoo!ニュース ゼルダ無双攻略Wiki｜厄災の黙示録 - AppMedia(アップメディア) 【テイルズオブルミナリア】リセマラ当たりランキング - TOルミナリア攻略Wiki - Gamerch(ゲーマチ) ウマ娘攻略Wiki - AppMedia(アップメディア) ゲトメア（ゲートオブナイトメア）攻略Wiki - Gamerch(ゲーマチ) 【白夜極光】リセマラ当たりランキング - 白夜 極光 wiki - Gamerch(ゲーマチ) お蔵入りとなった幻の『スーパーマリオ』 オランダの博物館でプレイ可能？（リアルサウンド） - Yahoo!ニュース - Yahoo!ニュース ナレッジ共有・社内wikiツール「NotePM」が「ITreview Best Software in Japan 2021」のTOP50に選出 - PR TIMES 真女神転生5攻略Wiki｜メガテン5 - AppMedia(アップメディア) 【B4B】近接ビルドデッキにおすすめのカード【back4blood】 - Gamerch(ゲーマチ) ポケモンスナップ攻略wiki - AppMedia(アップメディア) 富野由悠季「ブレンパワード」作り直したい！ファンを前に意欲（シネマトゥデイ） - Yahoo!ニュース - Yahoo!ニュース 【Apex Legends】ヴァルキリーの能力と評価【エーペックス】 - Gamerch(ゲーマチ) 【ウマ娘】査定効率から見た取るべきスキルとおすすめキャラ【プリティーダービー】 - Gamerch(ゲーマチ) ナレッジ共有・社内wiki「NotePM」が「ITreview Grid Award 2021 Fall」で、チームコラボレーションとマニュアル作成部門において「Leader」を5期連続でW受賞！ - PR TIMES メモ・ドキュメント・wiki・プロジェクト管理などオールインワンのワークスペース「Notion」が日本語ベータ版提供開始 - TechCrunch Japan 【ギアジェネ】リセマラ当たりランキング【コードギアス】 - ギアジェネ攻略Wiki - Gamerch(ゲーマチ) モンスターファーム2(MF2)攻略wiki｜アプリ・Switch移植版 - AppMedia(アップメディア) 【ブラサジ】最強キャラTierランキング【ブラックサージナイト】 - Gamerch(ゲーマチ) 【パワプロ】鬼滅の刃コラボ情報まとめ - Gamerch(ゲーマチ) アイドルマスターサイドM グローイングスターズ攻略Wiki - Gamerch(ゲーマチ) 【SPAJAM2021】第3回予選大会は「クイズ!WIKIにゃんず!」を開発したチーム「かよちゃんず」が最優秀賞！ | gamebiz - SocialGameInfo 検索結果における「ナレッジパネル」の役割とは・・・ウィキメディア財団とDuckDuckGoの共同調査 - Media Innovation ナレッジ共有・社内wikiツール「NotePM」が「BOXIL SaaS AWARD 2021 Autumn」にて「コラボレーション部門」を受賞！ - PR TIMES 【ウマ娘】ナリタブライアンの育成論｜URAシナリオ - Gamerch(ゲーマチ) Wikipediaが「中国人編集者の身の安全を守るため」に一部の編集者アカウントをBANに - GIGAZINE 【ウマ娘】ヒシアケボノの育成論｜URAシナリオ - Gamerch(ゲーマチ) 【ドッカンバトル】3.5億ダウンロードキャンペーン最新情報 - ドッカンバトル攻略Wiki - Gamerch(ゲーマチ) BTS（防弾少年団）のV、8月のWikipedia閲覧数が韓国アーティストで1位！グループでは4ヶ月連続トップ - Kstyle 【イース6オンライン】リセマラ当たりランキング｜召喚ガチャの開放条件は？ - Gamerch(ゲーマチ) BacklogからNotePMへwiki情報を自動API連携する「Backlog to NotePM」をSaaStainerに掲載開始 - PR TIMES ライザのアトリエ2攻略Wiki - AppMedia(アップメディア) 真女神転生3リマスター攻略Wiki｜メガテン3 - AppMedia(アップメディア) ガーディアンテイルズ（ガデテル）攻略Wiki - Gamerch(ゲーマチ) タスクも文書もWikiもデータベースもまとめて管理できる「Notion」とは？ - ASCII.jp ナレッジ共有・社内wikiツール「NotePM」が、見るだけ専用ユーザー『無料』の新プランを発表！ - PR TIMES 【かのぱず】リセマラ当たりランキング【彼女お借りします】 - Gamerch(ゲーマチ) 【パワプロ】討総学園高校の攻略とイベント一覧 - Gamerch(ゲーマチ) 【乃木フラ】リセマラの必要はある？【乃木坂的フラクタル】 - Gamerch(ゲーマチ) メトロイド ドレッド攻略Wiki - Gamerch(ゲーマチ) 【パワプロ】生放送まとめ｜パワフェス2021 - パワプロ攻略Wiki - Gamerch(ゲーマチ) 【ポケモンユナイト】サーナイトのおすすめビルド（わざ・持ち物） - Gamerch(ゲーマチ) ルーンファクトリー5攻略wiki｜ルンファク5 - AppMedia(アップメディア) ＜W寄稿＞韓国発の不純物によって汚された「スポーツ精神」＝韓日戦の野球で「反民族行為者」騒動（WoW!Korea） - Yahoo!ニュース - Yahoo!ニュース Wikipedia（ウィキペディア）が「寄付しない人」をディスり始めて笑った / 寄付し続けて5年目に来た催促メールがアツい！ - ロケットニュース24 簡単操作で自分専用Wikiを構築できるMarkdownエディタ「Obsidian」のモバイル版を使ってみた - GIGAZINE 【ウマ娘】体操服の変更方法と法則性 - Gamerch(ゲーマチ) 情報マネジメントツール「Huddler」がwiki機能を刷新 - PR TIMES 【ウマ娘】今後のロードマップ予想 - ウマ娘攻略Wiki - Gamerch(ゲーマチ) 【カウンターアームズ】改修のやり方とメリット【カタアム】 - Gamerch(ゲーマチ) シェアエコ配送アプリ「DIAq(ダイヤク)」のアンカーアプリで、高層ビル・商業施設の入館方法などお役立ち情報をまとめた「DIAq wiki」を公開 - アットプレス（プレスリリース） 異常熱波のカナダで49.6度、いま北米で起きていること（森さやか） - 個人 - Yahoo!ニュース - Yahoo!ニュース 【ツイステ】マスターシェフの攻略～辛味のふるさと～【料理イベント】 - Gamerch(ゲーマチ) 【ラグナロクオリジン】リセマラは不要？おすすめ職業は？【ラグオリ】 - Gamerch(ゲーマチ) 佐藤かよが公式YouTubeチャンネルを開設、自身のWikipediaを見ながら解説（エンタメNEXT） - Yahoo!ニュース - Yahoo!ニュース 【バイオミュータント】2.02アプデ｜アップデート1.4情報 - バイオミュータント攻略Wiki - Gamerch(ゲーマチ) ニーアレプリカントリメイク攻略wiki｜ver.1.22 - AppMedia(アップメディア) アイプラ攻略Wiki｜アイドリープライド - AppMedia(アップメディア) 【ウマ娘】ゴルシウィークはいつから？キャンペーン情報まとめ - Gamerch(ゲーマチ) シーズン66 - 【超速GP】ミニ四駆 超速グランプリ攻略まとめwiki - 電撃オンライン 【ウマ娘】チャンピオンズミーティングの攻略まとめ - Gamerch(ゲーマチ) 乃木坂的フラクタル攻略Wiki - Gamerch(ゲーマチ) 「こんなことになるとは…」13年前のエイプリルフールについた“嘘”がネットで… ある男の告白（BuzzFeed Japan） - Yahoo!ニュース - Yahoo!ニュース 整理不要の情報共有ツール(社内Wiki)「Nerve」シードラウンドで総額約3500万円の資金調達を実施 - PR TIMES 【ウマ娘】隠しイベントの発生条件と効果まとめ - Gamerch(ゲーマチ) Nerve - 整理不要の情報共有ツール(社内Wiki) ローンチカスタマー募集開始のお知らせ - PR TIMES 【テラクラシック】リセマラ方法や当たりペット【テラクラ】 - Gamerch(ゲーマチ) Among Us攻略Wiki【アマングアス・アモングアス】 - Gamerch(ゲーマチ) パニシンググレイレイヴン(パニグレ)攻略wiki - Gamerch(ゲーマチ) 稲作アクションRPG『天穂のサクナヒメ』における「農林水産省攻略wiki説」は本当なのか？ - AUTOMATON スタスマ攻略Wiki【スタースマッシュ】 - Gamerch(ゲーマチ) 無料とは思えない多機能っぷりなWikiインフラ「Wiki.js」レビュー、自前でホスト＆外部サービスと連携可能 - GIGAZINE Microsoft Teamsの基本と活用(24) TeamsのWikiを使う - マイナビニュース 『ゲーミングお嬢様』での提起が話題に “企業系wiki”に横たわる問題点とは - リアルサウンド 【リゼロス】Re ゼロから始める異世界生活 Lost in Memories攻略まとめwiki - 電撃オンライン 【世界初！】モノの背景を全方位で執筆できるVintage Wiki「VOV」を正式リリース - PR TIMES 足もとのベストアンサーを“編集”！ Wikiペディキュア！ - ビューティ特集 | SPUR - SPUR.JP パワプロ2021／2020攻略Wiki - Gamerch(ゲーマチ) ヌーラボ、「Backlog」の絵文字入力の補完機能やWiki編集の自動マージ機能を改善 - CodeZine（コードジン） ヌーラボ、プロジェクト管理ツール「Backlog」の絵文字入力の補完機能・Wiki編集の自動マージ機能を修正改善 - PR TIMES Backlog、Wikiにファイル添付が容易にできる機能をリリース -- グローバルバーの視認性改善なども実施 - PR TIMES GK川島、パンチング失点でWiki書き換え炎上 「セネガル代表」「プロボクサー」... - J-CASTニュース
https://w.atwiki.jp/cbah/pages/14.html
インスタグラムプラグイン 人気の画像共有サービス、Instagram(インスタグラム）の画像をアットウィキに貼れるプラグインです。 #ig_user(ユーザー名) と記載することで、特定ユーザーのInstagramのフィードを表示することができます。 例）@dogoftheday #ig_user #ig_tags(タグ名) と記載することで、特定タグのInstagramのフィードを表示することができます。 #dogofthedayjp タグ #ig_tag #ig_popular と記載することで、Instagramのpopularフィードを表示することができます。 詳しい使い方は以下のページを参考にしてください！ ＝＞http //www1.atwiki.jp/guide/pages/935.html
https://w.atwiki.jp/sampleisbest/pages/55.html
開発環境 Microsoft Visual C++ 2010 Express (SP1) 実行環境 Microsoft Windows XP Home Edition (SP3) プロジェクトの種類 Win32 コンソール アプリケーション プロジェクト名 test アプリケーションの種類 コンソール アプリケーション 追加のオプション 空のプロジェクト 文字セット Unicode Shift_JISに変換できないファイル名等を扱うためにUnicode対応が必要である。 また、セキュリティ強化関数の冗長化を防ぐためにC++のテンプレートオーバーロードを利用する。 C++でビルドするには拡張子をcppにする。 test.cpp #include fcntl.h // _O_WTEXT #include io.h // _setmode #include stdio.h // _fileno #include tchar.h // _tmain #include Windows.h int _tmain() { TCHARatcPath[_MAX_PATH]; TCHARatcDrive[_MAX_DRIVE]; TCHARatcDir[_MAX_DIR]; TCHARatcFName[_MAX_FNAME]; TCHARatcExt[_MAX_EXT]; _setmode(_fileno(stdout), _O_WTEXT); GetModuleFileName(NULL, atcPath, _countof(atcPath)); _tsplitpath_s(atcPath, atcDrive, atcDir, atcFName, atcExt); _tprintf(_T("[%s][%s][%s][%s]\n"), atcDrive, atcDir, atcFName, atcExt); return 0; } 実行 [C ][\hoge\][♥][.exe]